Closed Bug 414291 Opened 12 years ago Closed 12 years ago

Livejournal Insert/Edit URL button doesn't work. Pops up blank page.

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: avuton, Assigned: jst)

References

()

Details

(Keywords: regression, testcase)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008012008 Firefox/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008012008 Firefox/3.0b3pre

Livejournal.com Insert/Edit button doesn't work, it pops up a blank page. My wife remembers specifically it working before, but obviously a change in the webpage or Firefox has changed. Have tested with the nightly from tonight for windows and linux (build identifier). Will attach picture illustrating the button that doesn't work in the URL above.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-07-25+20%3A00&maxdate=2007-07-26+23%3A00
Caused by bug 280959?
I see the bug without login BTW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
Version: unspecified → Trunk
Wrong guess, it is bug 194404. Tested on Win XP and Vista.
Blocks: 194404
Attached file testcase
I managed to minimize it to this.
Flags: blocking1.9?
Keywords: testcase
Component: General → DOM
QA Contact: general → general
This is because they put "modal=yes" in the window.open feature string. IE ignores that whereas we open a modal dialog.
Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Flags: tracking1.9+ → blocking1.9+
So the easiest way to fix this would be to parse out the modal=... argument out of the options string in nsGlobalWindow::OpenInternal(), unless aContentModal is true. Parsing stuff out is sort of lame and hairy, but I don't see an easier way here. bz, anything else come to mind here?
As in, ignore modal="yes" like we used to for content dialogs, except those opened via showModalDialog()?  That sounds like the right approach to me...  It's not lame, and hopefully not even that hairy (since we used to do exactly that, except for all content cases), right?
bz, we used to ignore modal=yes in the window watcher code, but now we rely on that for communicating from the DOM code to the window watcher code that the window we're opening is a modal content window (i.e. showModalDialog()). To fix this bug w/o changing the showModalDialog()/window watcher interaction we'd need to parse the options argument in nsGlobalWindow::OpenInternal() and strip out modal=yes there. IOW one more options argument parser, that's the lame part.
Hmm.  That does seem lame, and more importantly fragile.

Could we stop piggybacking on the "modal" option, go back to ignoring it, and use a moz-modal-content-dialog option or some such to communicate with the windowwatcher?
Attached patch Fix.Splinter Review
This makes window.open() ignore modal=yes by reverting part of the changes we took when we added support for window.showModalDialog(), and makes the window.showModalDialog() code pass in a "-moz-internal-modal" option that the window watcher now has special code for.
Attachment #309305 - Flags: superreview?(bzbarsky)
Attachment #309305 - Flags: review?(bzbarsky)
Comment on attachment 309305 [details] [diff] [review]
Fix.

Looks good.  Get a test in too?
Attachment #309305 - Flags: superreview?(bzbarsky)
Attachment #309305 - Flags: superreview+
Attachment #309305 - Flags: review?(bzbarsky)
Attachment #309305 - Flags: review+
Attached patch tests.Splinter Review
Attachment #309505 - Flags: superreview?(jonas)
Attachment #309505 - Flags: review?(jonas)
Attachment #309505 - Flags: superreview?(jonas)
Attachment #309505 - Flags: superreview+
Attachment #309505 - Flags: review?(jonas)
Attachment #309505 - Flags: review+
Fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008031804 Minefield/3.0b5pre and the Win XP nightly. I used the Testcase in Comment 4 to verify.
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.