Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uBlock Origin makes skyscanner.com painfully slow to load #2896

Closed
birdie-github opened this issue Aug 25, 2017 · 3 comments
Closed

uBlock Origin makes skyscanner.com painfully slow to load #2896

birdie-github opened this issue Aug 25, 2017 · 3 comments

Comments

@birdie-github
Copy link

Filter issues MUST NOT be reported here. Read first: https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.md

Describe the issue

uBlock Origin makes skyscanner.com painfully slow to load

One or more specific URLs where the issue occurs

https://www.skyscanner.com

Steps for anyone to reproduce the issue

Open the website. See "Waiting for the extension" being flashed dozens of times.

Your settings

[If you fail to provide this info, I will mark the issue as invalid. Lists all settings which differs from default settings]

  • OS/version: CentOS 7.x
  • Browser/version: Chrome 64 60.0.3112.101
  • uBlock Origin version: 1.13.8

Enabled (in Settings):
☑ Hide placeholders of blocked elements
☑ Show the number of blocked requests on the icon
☑ Make use of context menu where appropriate
☑ Disable pre-fetching (to prevent any connection for blocked network requests)
☑ Disable hyperlink auditing
(everything else is disabled).

Your filter lists

EasyList
Fanboy’s Annoyance List​​​​​
RUS: RU AdList (Дополнительная региональная подписка)

Your custom filters (if any)

None.

@gorhill
Copy link
Owner

gorhill commented Aug 25, 2017

Site loaded fine here with uBO 1.13.8 and Chromium 60. Profiling show uBO's overhead is minimal, nothing unexpected.

The best problem with your issue is that you are no making the case: "Waiting for the extension" is not making the case that there is an issue with uBO. The browser offers all the tool to create profiling results to make the case about performance issue, you did not use this feature. Any speculated performance issue must come with profiling data minimally supporting the speculation.

Furthermore, as spelled out in CONTRIBUTING, if an issue is seen with the Canary version of Chrome, you must report it only if you can also reproduce with the stable version. You failed to do this.

Closing as "invalid" until you actually make the case.

@gorhill gorhill closed this as completed Aug 25, 2017
@birdie-github
Copy link
Author

birdie-github commented Aug 25, 2017

I'm running the latest stable Chrome release but since you're hellbent on closing this bug report I'm not gonna argue. I can reproduce it on three different PCs but who cares.

https://chromereleases.googleblog.com/2017/08/stable-channel-update-for-desktop_24.html

Also the requirement to profile your web browser is not mentioned anywhere. So much for posting bug reports.

Edit: their CDN works awfully. This looks like a problem with content loading, not with uBlock. It grabbed my attention because I'd never seen "Waiting for $(extension)" before.

@gorhill
Copy link
Owner

gorhill commented Aug 25, 2017

I'm running the latest stable Chrome release

Ok sorry, your reported version is "Chrome 64 60.0.3112.101", and I read this as Chrome 64-something. What you meant is Chrome 60.0.3112.101 (64-bit).

I can reproduce it on three different PCs but who cares.

I can't. Hopefully others will also try and weight in.

Provide profiling information with detailed steps-to-repro so that everyone can see that uBO is the cause of you slowdown. The browser contains all the tools for this, use the Performance pane. Here is an example of actually making a case -- using only the browser tools.

Contributing to open source is not dumping your speculations here for someone else to infirm/confirm, it's making minimum amount of efforts to validate your own assertions. In any case, I tried to reproduce and nothing came out of it, I profiled both the content script and background page and uBO was not anywhere to be a bottleneck on that page.

This looks like a problem with content loading

This is why making the case is key, it forces reporter to challenge their own conclusions: evidence-gathering is essential to prevent endless stream of spurious issues from being filed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants