search

uBlockOrigin / uBlock-issues

This is the community-maintained issue tracker for uBlock Origin
https://github.com/gorhill/uBlock
940 stars 80 forks source link

Cosmetic filtering not enforced at uBO launch on already opened web pages #403

Closed LittleVulpix closed 5 years ago

LittleVulpix commented 5 years ago

Prerequisites

Description

Blocking early requests no longer works on Waterfox with v1.18.0 . I see there was a recent commit that moved the feature to normal (from experimental) due to new api in Firefox, but since waterfox is a few versions behind, it does not have this API.

EDIT: I tested it just now with the latest "Legacy" uBO from github and it works properly again. Guess I should be using that one. Not sure if this is therefore even worth the report... perhaps some version detection to not use said api if not available? May be too much hassle, I understand. Even so, here it is. Feel free to close the issue if you think it is not relevant.

A specific URL where the issue occurs

Everywhere where you have a blocked element.

Steps to Reproduce

Described in detail here https://github.com/gorhill/uBlock/issues/1327 .

Basically a startup page browser opens with is not filtered.

Expected behavior:

Blocked objects are properly blocked on browser startup

Actual behavior:

Blocked objects are not blocked on browser startup

Your environment

uBlock-user commented 5 years ago

https://github.com/gorhill/uBlock/issues/1327#issuecomment-449717306

Probably a side effect of that.

Did Waterfox apply that patch ?

LittleVulpix commented 5 years ago

I had a look through https://github.com/MrAlex94/Waterfox/commits/master and I cannot find the 1447551 or 1503721 referenced, so I'm thinking not, which is why I suspected it broke with latest uBO

gorhill commented 5 years ago

Waterfox is not a supported browser.

LittleVulpix commented 5 years ago

Ah. That is sad; well, the legacy version works. Thanks for the reply.

gorhill commented 5 years ago

If the issue occurs with Firefox 56, I will look into it, but I don't install unsupported browsers locally, there has to be a limit in the amount of stuff I install on my computer.

By the way, I looked at the GitHub project of Waterfox, a great to see that the maintainer keeps the bugzilla bug id reference for each commit.

LittleVulpix commented 5 years ago

Yeah; it's a fun little project. A decent amount of people like it because it keeps compat. with older extensions as well as the new ones. But it's not updated as often. You know yourself how it is, maintaining a project on your own :) hehe. It's okay. Legacy uBO works, as long as you don't stop releasing that, Waterfox users should be fine.

gorhill commented 5 years ago

Actually, looking at the new code for blocking early request, I am not sure why there would be a change in behavior for FF56. The early blocking is now unconditional, and even without the bug fix in Firefox 61, the early requests should all be held back until uBO is ready.

The difference from before is that the early requests were cancelled (which is what still happen on Chromium), while now they are held back and properly evaluated when uBO is fully loaded. The Firefox fix was to ensure an extension's listener is registered as early as possible, which was an issue for either ways of blocking early requests.

So I wonder if your issue is more about cosmetic filters, since I can't figure how Firefox 56 would have its behavior changed with regard to early network requests.

LittleVulpix commented 5 years ago

I posted it previously -> https://github.com/gorhill/uBlock/issues/3451 ; it's the same issue. So I suppose it regards cosmetic filters. Back then, I was pointed to the "suspend tabs until ready" preference, which fixed the problem for me. Until v1.18.0 anyway.

gorhill commented 5 years ago

suspendTabsUntilReady forces a reload of the page, and this no longer happens now on Firefox with the new code.

If content scripts are not injected (content scripts are required for cosmetic filtering to work), then this means there is a chance stable Firefox would also be affected. However I created a test case and the filters, network and cosmetic, worked as expected:

Result: both the arrow gif and the origin strings are removed for each entry on the page, as expected.

LittleVulpix commented 5 years ago

Hmm, then I don't understand it. It started happening today when I updated to v1.18.0 - reproducibly so - and it stopped happening when I went back to my previous version of uBO. It also doesn't happen on latest uBO Legacy. I can provide more details if you need them, if you let me know what I should provide.

gorhill commented 5 years ago

If time allow I will try my test case above on FF56. What's the result of that test case for you with Waterfox?

LittleVulpix commented 5 years ago

I don't understand anything anymore. After I downgraded to legacy and now upgraded back to v1.18.0, it no longer occurs. It was happening entire day today (had to manually refresh the page on startup to make filtering work). But now... it works. On the test page you mentioned but also on my start page where it was previously broken. Because it did work after page reload then, I ruled out change of the element name, cause a reload would do nothing then.

Again, sorry. No idea what is happening. I don't know if "reinstalling" uBO did anything; I would imagine not. But it works now.

LittleVulpix commented 5 years ago

@gorhill actually I managed to capture it again. Seems intermittent but it still happens on v1.18.0 .

See recording below. And you can also see that after I refresh the page the cosmetic filter is correctly applied - but not before.

Filtering borked

Not sure what to make of it, or why it wasn't happening yesterday when I wanted to test it.

uBlock-user commented 5 years ago

suspendTabsUntilReady is experimental, so it may not work sometimes.

gorhill commented 5 years ago

From the look of your screenshot, this is a cosmetic filter issue, hence a content script injection issue. It's possible that the content scripts not being injected also affect Firefox stable. The browser is responsible for injecting the content scripts, and for some reasons as per your screenshot, this did not happen -- though network requests were blocked as per filter.

LittleVulpix commented 5 years ago

suspendTabsUntilReady is experimental, so it may not work sometimes.

It worked until v1.18.0, I assume by triggering a page reload as @gorhill said. (which I noticed a few times, but frankly I'm ok with a page being reloaded automatically than seeing ads and things I manually filtered out).

And yeah, this is a widget content which loads into the page as per your preferences. Our amazing primary search provider decided it was a good idea to be unable to remove some of the widgets and also to occassionally add some random ones they thought I'd be interested in. I filtered the whole section out, but with v1.18.0 it doesn't work anymore (not always anyway).

I noticed the page reload never happens either. I'm guessing because the suspendTabsUntilReadyis gone now as we rely on some new API from the new firefox?

gorhill commented 5 years ago

The auto reload was hiding the problem. There is code I added a while ago to manually inject content scripts at launch in case the browser didn't do it: https://github.com/gorhill/uBlock/blob/c3b0fd31f64bd7ffecdd282fb1208fe07aac3eb0/src/js/start.js#L80.

So apparently this code is not working on your side, but it seems to be working on my side. So I wonder if this is caused by a fix in Firefox which did not make it into Waterfox.

LittleVulpix commented 5 years ago

A thing to note perhaps is that it was not waterfox that was updated; it was uBO. I.e. nothing changed @ Waterfox side, I've been using this version for about a month and it worked fine. It only broke when uBO updated. I have a full backup of my old profile and when I opened it, I found that I was using version

"version": "1.17.4",

prior to updating to v1.18.0. The release date of 1.17.4 would suggest it already contained the aforementioned change though, so that's odd...

If you have some question or a test you would like me to do with my waterfox, please let me know. Thanks!

gorhill commented 5 years ago

nothing changed @ Waterfox side

As said, the auto-reload is now gone, so the code above should have picked up the cosmetic filter counterpart of dealing with early filtering.

I am running tests and it seems it's not working on Firefox stable either, but it's working with Chromium. The test is simple:

Expected result: the cosmetic filters should have been applied in the already opened HN tab.

This works on Chromium, not on Firefox stable, neither on Nightly.

gorhill commented 5 years ago

I inserted console.log call to find out what happens in Firefox and got the following from the content script when launching uBO with an already opened tab:

retrieveContentScriptParameters https://news.ycombinator.com/ contentscript.js:1780:5
No matching message handler for the given recipient. MessageChannel.jsm:924
    _handleMessage/</< resource://gre/modules/MessageChannel.jsm:924:11
bootstrapPhase1 null contentscript.js:1700:9

So it seems Firefox is not able to properly dispatch the message to uBO's main process.

gorhill commented 5 years ago

For reasons unknown, the messaging port in the content script is being disconnected. thus causing the content script to be unable to talk to the main process.

gorhill commented 5 years ago

If I delay (using requestIdleCallback) the call from the content script to query uBO's main process, the cosmetic filtering is properly applied at launch -- i.e. no spurious port disconnection occur. Of course this is not a solution but this narrows the issue. At this point I am unsure whether the spurious port disconnection is a by-design issue or an actual issue with the webext framework.

gorhill commented 5 years ago

So far:

LittleVulpix commented 5 years ago

Sounds like a pretty fun (and odd) issue to investigate :D Good luck!

LittleVulpix commented 5 years ago

@gorhill Hi! The fix works on Waterfox as well. I can see the blocked elements showing for a split second before disappearing on initial browser start - which (from what I understand) is how it should work - the uBO filtering is injected into the page after it loads.

Thanks for the fix!