Closed Bug 454613 Opened 16 years ago Closed 6 years ago

showModalDialog(...) is not executing javascript, throws assertion in nsWindowWatcher::ReadyOpenedDocShellItem

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
fennec1.0b1

People

(Reporter: jmaher, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080909144134 Fennec/0.7 Run this .html file inside fennec and you will get an alert box with "null". Run inside of FF3 and you will get "foo". <html><head></head><body> <script type="text/javascript"> var result = window.showModalDialog("javascript:window.returnValue = 'foo'; window.close();"); alert(result); </script></body></html> Reproducible: Always Steps to Reproduce: 1. Run the above .html file in fennec 2. Observe the alert is "null" instead of "foo" Actual Results: New window is launched, but doesn't appear to be executing javascript code. Expected Results: New window to be launched, javascript to execute, and return value passed to parent window I see this in the console: ###!!! ASSERTION: Why is there a document channel?: '!chan', file /home/joel/mozilla/mozilla-central/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 1777
Flags: in-testsuite+
This bug is blocking the full mochitest run, therefore, it should block fennec 1.0 as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-fennec1.0?
neil, is this something you can take a look at?
Assignee: nobody → enndeakin
Flags: blocking-fennec1.0? → blocking-fennec1.0+
Target Milestone: --- → Fennec A2
Looks like about:blank is being loaded into the window but hasn't finished yet by the time the assertion is hit. This gets into a network or threads issue and is beyond anything I could do at the moment.
So, if we are seeing null in *both* firefox and fennec, and then why does the mochitest pass in firefox? Possibilities: * Firefox is broken and alternately reports different things * The mochitest is broken and always reports pass regardless of the return value * Something entirely different is failing the mochitest on fennec Note that all of these (or some combination) may be true. We need to figure out which ones are true and how to resolve this issue. Joelm, can you do the qa triage on this and try to understand what we're seeing?
(In reply to comment #4) > http://people.mozilla.org/~dougt/showModalDialog.html > > i see null in firefox. That means you have popup blocking enabled. It doesn't return null if you disable it.
ah, If Fennec has different prefs than Firefox, namely the ones here: http://mxr.mozilla.org/mozilla-central/source/build/pgo/automation.py.in#295 then tests could certainly fail. Not sure if that's the problem here.
okay, there are a couple things going on. First: We do set the pref "dom.disable_open_during_load" to true in our fennec preferences. This probably is preventing the popup at all. We need to change that / remove that. I thought that the user_prefs would override the stuff in mobile.js (or all.js) Secondly, i do not think we support "modal dialogs" in Fennec yet -- or at least we are supporting them somehow differently than what firefox does. When I type this into the url bar in fennec: javascript:window.showModalDialog("javascript:window.returnValue = 'foo'; window.close();") I do not see the javascript executing, but I do see a new window opening and the opener waiting for the window to be closed. Neil: any ideas of what prefs I might be missing?
Blocks: 450708
It looks like we hit a second mochitest case related to this. If we can get this fixed the mochitests can run fully automated which will help us identify regressions faster.
this bug has been idle for 4 weeks. As discussed in the Monday meeting, can we get some traction on this bug before end of week?
I looked at this quite a bit more but haven't got any additional insight. The sequence of steps is: - request is made to open a modal dialog - about:blank is loaded into the modal window but doesn't finish loading yet - events are processed, and chrome://browser/content/browser.xul finishes loading. The assertion above is output as about:blank is still loading in the window. - this causes the request to be made to load the javascript url. - the script itself is evaluated asynchronously - due to this asynchronousness, more events are processed and the previous about:blank finishes loading. - the script inner window is now different (about:blank versus javascript url window I think), so fails in nsJSThunk::EvaluateScript The bug is that about:blank does not finish loading. I don't think this is caused by a missing preference as I ran with the preferences copied from firefox as well with the same issue. Anyway, apart from it being used in a test, I don't see why this would be particularly significant issue. Certainly not worth my spending time on it.
The bug is significant because this is what several mochitests do, and we can't turn on mochitests for mobile until we get these blocking issues fixed. There are three solutions possible here: 1. Assume the test is "broken" and fix the test. 2. Turn off the test 3. Fix Fennec You can't just assume the test is broken since it was reviewed and checked in against Firefox, where it still passes. Several tests use this trick to do testing, and we can't run a full suite of mochitests without them. *** This means, we can't turn on automated testing until we get this problem fixed.*** If we start turning off tests that are failing on fennec, that gives us an incorrect measurement of fennec's quality. As of the people responsible for Fennec's quality, I oppose this. That leaves us with Fix Fennec, which I think is worth spending time on and doing. I'm sorry if it's an annoying bug, we still need to fix it.
> If we start turning off tests that are failing on fennec, > that gives us an incorrect measurement of fennec's quality. Not that we would get a correct measurement even if the tests did work of course :) > That leaves us with Fix Fennec, which I think is worth spending time on and > doing. I'm sorry if it's an annoying bug, we still need to fix it. The number of actual web sites that depend on opening javascript urls in a modal dialog is probably fairly slim, so I don't think fixing this has higher priority than other more useful bugs I could be fixing.
Assignee: enndeakin → nobody
Looking at this a bit more and I've found that it's the test for bug 391777 that is failing, which did originate with a website. However, the website was doing a more standard modal dialog, not using a Javascript URL. Fennec will pass the original test submitted with that bug, but won't pass the mochitest, so this is a good case for disabling this bug or changing the test. I've opened bug 464081 to track this issue (and any others like it that we find).
Depends on: 464081
Target Milestone: Fennec A2 → Fennec A3
Flags: blocking-fennec1.0+ → wanted-fennec1.0+

The showModalDialog API was disabled in Firefox 56 and removed later on. As a result, I believe this bug is no longer present in (more) recent versions of Firefox. Please reopen and needinfo me if you think this bug is still relevant.

Bugmail filter: showModalDialogClosure.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.