Closed Bug 519528 Opened 10 years ago Closed 10 years ago
ireflow breaks layout of default browser dialog
The dialog which appears asking to make Firefox the default browser has a broken layout when ireflow settings are enabled, and the way the layout is broken depends on the settings. To reproduce: - set browser.shell.checkDefaultBrowser to true - make an older browser (e.g. FireFox 3.5) the default browser - unset GECKO_REFLOW_INTERRUPT_MODE - unset GECKO_REFLOW_INTERRUPT_FREQUENCY - export GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=0 - launch the browser Result: there are 4 or 5 lines of blank space between the dialog text and the "Yes"/"No" buttons. - export GECKO_REFLOW_INTERRUPT_MODE=counter - export GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=0 - export GECKO_REFLOW_INTERRUPT_FREQUENCY=0 - launch browser Result: There are 4 or 5 lines of blank space between "Namoroka is not currently set as your default browser. Would you like to make it your default" and "browser". That is, the blank space noted above has shifted up to appear in the middle of a sentence. The layout of the dialog is normal if all the GECKO_REFLOW variables are unset.
found on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b1pre) Gecko/20090929 Namoroka/3.6b1pre (.NET CLR 3.5.30729)
Hmm. Perhaps we should disable ireflow under xul or something... I'll try to figure out what's going on here, but if someone can come up with a standalone xul testcase that shows the problem, that would be a huge help.
I extracted the default browser prompt from browser code and stuck it into the attached xul file. Interestingly, the rendering problem does not appear in this version. However, if you save the file locally and pass it to firefox using the -chrome command-line flag, an internet security prompt will appear, and the layout of this dialog is completely mangled, if the three GECKO ireflow env variables are set as described above.
Attachment #403598 - Attachment description: testcase (see comment) → testcase (see comment #3)
Yeah, I bet what's messing up here is the combination of ireflow and the size-to-content reflow. I'll look into that. Thanks for the testcase!
Hmm. So with that testcase I can't reproduce on Mac, but it might be that the codeflow is just slightly different there... In any case, the patch for bug 519590 might fix this (by disabling interruption in chrome prescontexts). Worth retesting once that lands.
Depends on: 519590
I tested this with the fix from comment #5, on the original machine the problem was observed on, and could not repro the bug. Tested on: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b1pre) Gecko/20091007 Namoroka/3.6b1pre (.NET CLR 3.5.30729)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.