519528 - ireflow breaks layout of default browser dialog

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jonathan Griffin (:jgriffin)]

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.

Comment 1

[Jonathan Griffin (:jgriffin)]

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)

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Jonathan Griffin (:jgriffin)]

Attachment: testcase (see comment #3)

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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!

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Jonathan Griffin (:jgriffin)]

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)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Excellent!