Closed Bug 735237 Opened 10 years ago Closed 10 years ago

window.showModalDialog causes weird issues


(Firefox for Android Graveyard :: General, defect)

Not set


(firefox14 verified, firefox15 verified, blocking-fennec1.0 +)

Firefox 14
Tracking Status
firefox14 --- verified
firefox15 --- verified
blocking-fennec1.0 --- +


(Reporter: martijn.martijn, Assigned: mbrubeck)




(Keywords: testcase)


(2 files, 2 obsolete files)

Attached file testcase
See url testcase, steps to reproduce:
- Tap on the window showModalDialog() button (second to last button)

Expected result:
- A new window opens with that page, which has an input a 'Close' button, a link and some text in it.

Actual result:
- The page seems to get opened in the same window, it's completely zoomed in, so that nothing is visible. Tapping on the Android back button doesn't seem to go back to the previous page.
blocking-fennec1.0: --- → ?
Assignee: nobody → mbrubeck
blocking-fennec1.0: ? → +
Note: XUL Fennec throws an exception (NS_ERROR_FAILURE in nsIDOMWindow.showModalDialog) and fails to open a window.

It's not clear how we could/should support modal content windows in Fennec.  Proper support would require that we freeze content in the main window and prevent the user from interacting with it until the modal page is dismissed.  Unless we have a good UX design, it's probably best to throw an exception like XUL Fennec.

For comparison, none of the main competing browsers handle showModalDialog correctly:

* Opera Mobile does not open the URL, but displays a dialog with just an "OK" button.
* Stock Android Browser does not open the URL, but displays a dialog with the text "undefined" (in both Android 2.3 and 4.0)
* Chrome opens the URL in a new tab but the tab is not modal (on both Android and desktop).
Attached patch patch (obsolete) — Splinter Review
This patch makes window.showModalDialog throw an exception in fennec.  Johnny, do you think this is the best approach and implementation?  I'd also like to do basically the same thing for window.print in bug 739038.
Attachment #614184 - Flags: feedback?(jst)
Attached patch patch (obsolete) — Splinter Review
Oops, accidentally uploaded an empty file.  (Thanks, Margaret.)
Attachment #614184 - Attachment is obsolete: true
Attachment #614202 - Flags: feedback?(jst)
Attachment #614184 - Flags: feedback?(jst)
Comment on attachment 614202 [details] [diff] [review]

This makes sense to me until we have the UX bandwidth to figure out exactly how this should work on a mobile device, if at all.
Attachment #614202 - Flags: feedback?(jst) → feedback+
Try run for e9b15bc58060 is complete.
Detailed breakdown of the results available here:
Results (out of 55 total builds):
    success: 48
    warnings: 6
    failure: 1
Builds (or logs if builds failed) available at:
Attached patch patch with testSplinter Review
Same as the previous patch but adds a simple mochitest.
Attachment #614202 - Attachment is obsolete: true
Attachment #614578 - Flags: review?(jst)
Attachment #614578 - Flags: review?(jst) → review+
Target Milestone: --- → Firefox 14
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 753555
An error occurs when showModalDialog() button is tapped:

E/GeckoConsole(25018): [JavaScript Error: "NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindow.showModalDialog]" {file: "" line: 14}]

Since this is expected (comment #2), this bug will be closed as verified fixed on:

Firefox 15.0a1 (2012-05-30)
Firefox 14.0a2 (2012-05-30)

Device: Galaxy Nexus
OS: Android 4.0.2
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.