User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Steps to Reproduce:
2. Go to another web page
3. Go back to the original page (e.g. by pressing backspace)
4. Trigger the alert() or confirm()
A window-modal dialog opens.
The content-/tab-modal dialog should open.
I can reproduce using Minefield on Linux using my main profile, but can't reproduce it in a new profile on Linux or Windows.
More precise STR (especially because I have backspace not as back):
2: scroll down a bit and click the button labeled "Leave Tizag.com"
3: click ok to the tab-modal prompts twice
4: script sends you to Google
5: click back and repeat step 2
6: prompts are now the old modal dialogs, instead of tab-modal prompts
Dupe of bug 629911?
(In reply to comment #2)
This looks nothing like that.
I've managed to reproduce this on Linux and Windows starting from a new profile now. The missing ingredient: install Adblock Plus 1.3.3
CCing Wladimir. I'm worried that somehow Adblock might accidentally be causing web JS to run in a different context that gets out of the tab-modal prompts. Worst-case scenario would be if it causes it to be run with chrome privileges.
Notes: Also tried with latest Adblock Plus dev build with same results. Used Easylist subscription with tests.
Created attachment 515510 [details]
Minimal content policy extension for testing
Content policies was were I would expect the problem to be coming from.
I can't seem to reproduce it using the attached test extension, however. Anything extra I need to do besides installing it into a new profile?
Works For Me with a clean profile on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Works For Me with Adblock Plus 1.3.3 installed on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Created attachment 515575 [details]
Minimal content policy extension for testing
My bad, I forgot that the content policy extension in my profile was a modified version. Attached the modified version now, verified that it will cause the issue on a clean profile (Minefield build 20110227 on Windows 7). It seems that having a content policy is not enough, one also has to block a script on the page - and that's what this extension is doing now (blocking http://pagead2.googlesyndication.com/pagead/show_ads.js request).
Ah, ok. Now I can reproduce using your second testcase extension. Thanks.
I'll confirm this and move it over to Core:General. Not sure exactly what component it belongs in, though.
Justin, any idea what's going on here? Are we somehow getting confused about which tab the dialog belongs to?
I reduced the content JS part of the testcase and put it in a data URI above. Note that this is reproducible with just one confirm(), or one alert(), or one prompt(). Same effect for each: navigate to another page and back and then it'll be window-modal instead of content-modal.
Just to be clear, the test extension is blocking "/show_ads.js" but the test content JS doesn't need to have the file being blocked. I can still reproduce with it with only a button for a prompt and the test extension.
(In reply to comment #9)
> Justin, any idea what's going on here? Are we somehow getting confused about
> which tab the dialog belongs to?
Hmm. I'd actually guess this is a result of the code added in bug 613800, which forces use of window-modal prompts in some cases (ie, when a tab-modal prompt could result in unexpected reentrancy).
Still seems unexpected here, though, so maybe some of the existing accounting which 613800 checks is incorrect?
I can reproduce this with my normal profile on OS X (which has Adblock), but not yet on my Windows box. Lemme try again with the STR from the last few comments.
I can reproduce on Windows now.
In DocumentViewerImpl::GetIsTabModalPromptAllowed(), mHidden is |true|. Which I guess isn't actually surprising, because there doesn't seem to be any code to set it back to |false| when a previous-hidden page is no longer hidden. Sigh.
Er, yeah. Looks like Show() should set mHidden to false? I wonder why that ever worked...
Created attachment 515826 [details] [diff] [review]
This fixes the problem for me.
Any other places that mHidden should be reset? I don't know this code well enough to say, but this seems like the obvious missing spot.
::Stop() is the only other place mHidden is checked [other than ::GetIsTabModalPromptAllowed()], so this seems safe enough.
Hmm, why do the STR need a content policy to trigger this? I don't see an obvious connection, does the policy have some effect on bfcache / when things are shown or hidden?
> Hmm, why do the STR need a content policy to trigger this?
This part I don't know. It seems like any time a page comes from bfcache we should hit this problem, no?
Comment on attachment 515826 [details] [diff] [review]
Does putting this in Open() also work? It would make a bit more sense there, I think... r=me either way.
*** Bug 647577 has been marked as a duplicate of this bug. ***
*** Bug 648236 has been marked as a duplicate of this bug. ***
Created attachment 525148 [details]
I'm seeing it also in this case, when adding an alert in a pageshow event. I guess the patch will fix the issue.
*** Bug 650301 has been marked as a duplicate of this bug. ***
Why is this patch not landed yet?
Note that there is a pending review comment on the patch. Please don't check it in without addressing that comment.
Exactly what I was going to say when you midaired me! :)
*** Bug 648627 has been marked as a duplicate of this bug. ***
Created attachment 526444 [details] [diff] [review]
Moved mHidden reset from ::Show() to ::Open(), still fixes bug.
Adjusting summary, since I don't see anything to indicate a content policy is actually required to trigger this bug. Feel free to retest after this lands, and if there's still some remaining issue involving a content policy, let's file a new bug (and just refer to this one for some of the history).
*** Bug 673099 has been marked as a duplicate of this bug. ***
Seeing this in the latest 7.0 beta with AdBlock Plus installed. Can confirm that disabling ABP and reloading the page fixes the problem.