430996 - JS is being disabled "stickily" in recent builds

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Christopher Blizzard (:blizzard)]

Attachment: sessionrestore.js that contains the disallow:"Plugins,Javascript" flag

I was tracking a problem while developing a web application on localhost where JS files for a particular page were not being loaded.  I eventually tracked it down to my sessionrestore.js preventing JS on localhost from ever being loaded.  Not force reloads, not clearing cache, nothing.  It just wouldn't load JS files no matter what I did.

My new sessionrestore.js file doesn't contain the disallow flag so it's no longer a problem but I have no idea what triggers that being added and should it continue to affect pages loaded after the initial session restore?

I'll attach the sessionrestore.js file that caused the problem.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Session store just saves/restores the allow* attributes from the docshell:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/sessionstore/src/nsSessionStore.js&rev=1.100#912

Not sure how this could get in there unintentionally... had you disable JS and plugins in the session at some point? Perhaps with the webdev toolbar?

Comment 2

[Christopher Blizzard (:blizzard)]

I've never changed those settings in my life.

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> I've never changed those settings in my life.

Yeah, they always say that. ;-) Then again: SessionStore surely didn't, either - it just preserves them at the docshell's wish (and then leaves it to the docshell to reset them, which BTW it doesn't onload but only when explicitly told so).

So: What extensions do you have installed (resp. did you have installed when it happened)? And are there any other potential oddities with that specific profiles we might want to know about?

Comment 4

[Christopher Blizzard (:blizzard)]

I use firebug and weave and that's it.  Nothing strange about this profile that I know of except that it's pretty new and was only used for this development process.

Comment 5

[Simon Bünzli]

(In reply to comment #4)
> I use firebug and weave and that's it.

Grepping both Firebug 1.05 and 1.1b12 and the latest Weave from http://people.mozilla.com/~cbeard/weave/dist/latest-weave.xpi didn't yield any results for accessing/modifying docShell properties. It's a mystery.

Comment 6

[Brendan Eich [:brendan]]

This happened to me too. I'm trying to rid my profile of it. I have adblock plus, personas, linky, user agent switcher, js debugger. Disabling those all did not help.

I noticed that JS is re-enabled when I load about:config. Then I can, e.g., type javascript:"hi" in the URL bar and see hi (the generated page). If I go back to the site (youtube video) where I noticed that JS was off, however (even if I force-reload), JS is disabled again -- and javascript:"hi" is ignored. Another round of about:config fixes things temporarily.

There: I edited my profile to remove the two disabled:"Plugins,JavaScript" property initialisers and all is well again.

So this is not a session restore bug. It is a recent regression in the docshell or near it, from the sound of things. Anyone care to suggest a regressing change?

/be

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This sounds like a blocker to me. JS not running will break a lot of websites

Comment 8

[Mike Shaver (:shaver emeritus)]

I'm not one to blocking+ lightly at this stage, but "JS is disabled" sounds like a winner. :/

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Brendan: Does the javascript:"hi" thing only work when about:config is the current tab? If so that is likely due to the fact the the url is loaded (and thus the js executed) in the context of the current tab, which for about:config is a chrome tab.

Comment 10

[Brendan Eich [:brendan]]

(In reply to comment #9)
> Brendan: Does the javascript:"hi" thing only work when about:config is the
> current tab? If so that is likely due to the fact the the url is loaded (and
> thus the js executed) in the context of the current tab, which for about:config
> is a chrome tab.

No, javascript:"hi" and similar works in any Mozilla release, in Netscapes going back to 2, and I hope in other browsers (I test some from time to time), when typed into the URL bar. Try it. It's working for me in all contexts now.

/be

Comment 11

[Christopher Blizzard (:blizzard)]

I don't think that I included this in my original bug report but the symptom I was seeing was that JS was being disabled for only the host (or tab?) that was in the original sessionrestore.js file.  In my case that was localhost, but it could have been anything.  So it's at least per-tab and maybe per-host?  I don't remember trying opening a new tab and opening localhost.

JS was working fine on other sites in other tabs.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So I talked to Brendan and when he's running into this bug the 'javascript:"hi"' thing only works while the current tab is about:config. Switching to another tab makes it not work again. So it's not possible to get us back into a good state by switching to/from about:config, we always remain in the bad state for the other docshells.

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

Attachment: sessionstore with locked js on tinderbox page

I too have seen this and am attaching my sessionstore.js file.  I usually have the tinderbox page up and on a few occasions now I've seen the 'Sheriff' box disappear and leave the text about javascript being disabled.  

I have no idea how this is being mitigated at the time.  One I'm sure was caused by a crash, other times seem random.  

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050116 Minefield/3.0pre Firefox/3.0 ID:2008050116

Vista HP SP1
extensions: TabMix Plus, Chatzilla, Sage, NTT (nightly tester tools), Statusbar Clock, Forecastfox and Console2

I've never used NoScript or AdBlock in any form.  

Hope this helps some..but may be rehash of things already known...

Comment 14

[:Gavin Sharp [email: [e-mail]]]

nsHTMLDocument::EditingStateChanged calls DisableJSAndPlugins() which ends up calling SetAllowJavascript(PR_FALSE), and relies on RestoreJSAndPlugins() being called to restore that state. Bug 386782 touched editor code and has several outstanding regressions that seem to be related to not properly restoring state during navigation.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

The patch in bug 430624 looks like it might fix this.

Session store is probably just exacerbating the problem by always restoring the "disable javascript" flag on the docshell when it restores the session.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

blizzard: does that web application you were testing use contentEditable?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Does sessionstore restore the editable state too?

Comment 18

[Brendan Eich [:brendan]]

(In reply to comment #12)
> So I talked to Brendan and when he's running into this bug the
> 'javascript:"hi"' thing only works while the current tab is about:config.
> Switching to another tab makes it not work again. So it's not possible to get
> us back into a good state by switching to/from about:config, we always remain
> in the bad state for the other docshells.

Jonas kindly pointed out what I was being thick about: chrome always gets JS enabled, and about:config is chrome, so the javascript:"hi" works when evaluated against that privileged page.

So is this a dup of bug 430624? At the least it could depend on that bug.

/be

Comment 19

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is definitely caused by 386782, and it's fixed by the patch 430624 (which is waiting for someone to check it in).

STR:
1. Load http://youtube.com/watch?v=mHXBL6bzAR4
2. Scroll up and down a bit with the cursor keys.
3. Enter javascript:"hi" in the URL bar.
4. Once the "hi" page has loaded, press the up and down cursor keys a few times.
5. Navigate back with ALT+LEFT keys.
6. YouTube will display a "You have JS disabled" box instead of the video.

I think this is another case of detach/reattach editor not working correctly. Once 430624 is checked in this will be fixed.

I'm currently running a TryServer build with 430624's patch in it, I'll post a link when it's done, so that you guys can make sure that fixes it.

Comment 20

[Chris Pearce [:cpearce (Not reading bugmail)]]

TryServer builds with 430624 patch will appear here in the next hour or so, Mac build is already there:

https://build.mozilla.org/tryserver-builds/2008-05-01_19:[e-mail]-430624-v2/

Comment 21

[Christopher Blizzard (:blizzard)]

gavin: No, it does not.

Comment 22

[Peter Van der Beken [:peterv]]

Marking this fixed (used steps from comment 19 to reproduce). Please reopen if this is not completely fixed by the patch for bug 430624. We should make an automated test for this one.