Javascript sometimes fails to run even though it's allowed

[paxunix]

I see this most frequently with Gmail. I have set up HTTPSB "from scratch", choosing "Allow all / block exceptionally" and then whitelisting everything for *.google.com. Still, when first opening my browser with about 10 tabs, I will occasionally see the complaint from Gmail that Javascript must be enabled. So something in HTTPSB makes the page think that JS is disabled, even though it's been whitelisted. Reloading the page puts everything right.

[ghost]

Not sure if it is related, but I am block only, and sometimes my Gmail
gets stuck in a loop, in what I am guessing is a JS issue. I'll have
to test it further because I have so many variables in play.

On 8/19/14, Shawn Halpenny notifications@github.com wrote:

I see this most frequently with Gmail. I have set up HTTPSB "from scratch",
choosing "Allow all / block exceptionally" and then whitelisting everything
for *.google.com. Still, when first opening my browser with about 10 tabs,
I will occasionally see the complaint from Gmail that Javascript must be
enabled. So something in HTTPSB makes the page think that JS is disabled,
even though it's been whitelisted. Reloading the page puts everything
right.

---

Reply to this email directly or view it on GitHub:
#399

[gorhill]

when first opening my browser with about 10 tabs, I will occasionally see the complaint from Gmail that Javascript must be enabled

By the way you describe it, quite certainly due to the fact that extensions cannot block the browser in Chromium-based browsers.

HTTPSB naturally works in block-all mode, so here is what is probably happening:

1. Launch the browser
2. HTTPSB is loaded and launched by the browser
3. HTTPSB starts the reading of all the user settings + filter lists
4. The GMail tab is loaded in the browser
5. HTTPSB blocks javascript in GMail tab (because it blocks by default)
6. HTTPSB finishes the reading of all the user settings + filter lists
7. Now HTTPSB will correctly allows/blocks net request as per user's settings
8. But the GMail tab was already loaded, so too late for the proper settings to take effect

You would need to force refresh the GMail tab to ensure the tab works properly as per your allow/block rules which are now fully loaded.

It's by design that the browser doesn't allow extensions to block web pages, so there is nothing I can do.

[Tanath]

Many Google pages depend on other domains too, like gstatic.com googleusercontent.com and ggpht.com.

[ghost]

what gorhill said above seems to explain why #405 happens

[gorhill]

I am working to speed up load time with uBlock, will see how well this help. If it does work well for uBlock, then this means the issue could also be mitigated for HTTPSB. I use the word "mitigated" because as said, it's a by-design that extensions can't block the browser, so the only solutions left are to speed up load time of extensions and hope extensions will win the race and load fully before tabs.

[ghost]

You mean that the extensions and the browser part are started like in parallel? I wonder how hard would it be to patch the chromium code to make the browser part wait until the extensions are all loaded.

[gorhill]

I just saw that Opera 23 has a setting "Delay opening of background tabs", which mitigates the problem here -- at least for those tabs which are not in the foreground at load time.

[ghost]

I wish background tabs would "start" just like in firefox - they don't start, only their favicons get updated; they load only when brought into foreground/focus.

I'm looking into this:
http://sourceforge.net/p/footab/code/ci/master/tree/src/background.js
(although I know no javascript/chromium/html whatever ;) )

Next would be OneTab extension.

EDIT: FooTab just works (EDIT2: ok almost!)flawlessly !