498340 - Repaint issue when I open a sidebar

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090615 Firefox/3.5.0 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090614 Minefield/3.6a1pre ID:20090614050328

The drawing of contents becomes funny when I open a sidebar

Reproducible: Always

Steps to Reproduce:
1.Start Minefield with New Profile
2.View > Sidebar > History  (do not ctrl + h)
3.
Actual Results:  
The drawing of contents becomes funny.

Expected Results:  
The drawing of contents should be painted pictures definitely.

Comment 1

[Alice0775 White]

Attachment: Screen shot

Comment 2

[Alice0775 White]

You may have to repeat "step 2" 2 or 3 times to reproduce this problem.

Regression range:

Works fine:
http://hg.mozilla.org/mozilla-central/rev/497fe6fed36e
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre ID:20090611185346

Broken:
http://hg.mozilla.org/mozilla-central/rev/b3c4e464fed7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre ID:20090611210216

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=497fe6fed36e&tochange=b3c4e464fed7

Comment 3

[Alice0775 White]

Sorry, the regression range in Comment #2 is wrong.
however , http://hg.mozilla.org/mozilla-central/rev/497fe6fed36e is also broken .

Comment 4

[Alice0775 White]

Corrected regression range:

Works:
http://hg.mozilla.org/mozilla-central/rev/89811ac1b35a
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090114 Firefox/3.2a1pre ID:20090114034711

Broken:
http://hg.mozilla.org/mozilla-central/rev/73fbb12f48e1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090115 Firefox/3.2a1pre ID:20090115033950

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=89811ac1b35a&tochange=73fbb12f48e1

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Nothing in that regression range jumped out at me.  A narrower range might be more useful, although maybe roc will see something suspicious.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, I don't see anything suspicious

Comment 7

[Alice0775 White]

To reproduce it surely,
step 2. View > Sidebar > history & Hold left click a while
repeat "step 2" 2 or 3 times to reproduce this problem.

Comment 8

[Alice0775 White]

I backed out 40ba2eac8f4b and build Minfield, the issue does not occur.
So, I suspect bug 472730.

Comment 9

[Alice0775 White]

This problem does not seem to reappear since the following build.
http://hg.mozilla.org/mozilla-central/rev/5b0d9f36c0b3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090721 Minefield/3.6a1pre ID:20090721192005

Therefore,I assume it resolved at present.

Comment 10

[Alice0775 White]

Sorry, There is still the problem.
It occurs frequently in a page of about:buildconfig with new profile.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090807 Minefield/3.6a1pre ID:20090807045043

Comment 11

[Alice0775 White]

Attachment: avi

Comment 12

[Nochum Sossonko [:Natch]]

Attachment: screenshot - about:buildconfig

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090816 Minefield/3.7a1pre
Confirmed. Notice the about:buildconfig page extends beyond the right border of the window, the box didn't resize it self appropriately.

Comment 13

[Alice0775 White]

This repaint issue happens on persona page http://www.getpersonas.com/en-US/gallery/Foxkeh/Popular .

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091030 Namoroka/3.6b2pre ID:20091030060000
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1
and
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091030 Minefield/3.7a1pre ID:20091030060356

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Alice, can you be more specific? You mean opening the history tab while at that Personas page causes the problem?

Comment 15

[Alice0775 White]

(In reply to comment #14)
> Alice, can you be more specific? You mean opening the history tab while at that
> Personas page causes the problem?

STR:
1.Start Browser with new profile
2.Open http://www.getpersonas.com/en-US/gallery/Foxkeh/Popular 
3.View > Sidebar > History (repeat this several times if necessary, Do not use short-cut or Toolbar button)

Actual result:
Repaint issue happens.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks, I can reproduce this.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase

Load this testcase, then show the sidebar. The right border doesn't repaint correctly, for me. May be Windows only, I can't reproduce on Mac.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Here's what I think is happening:
* When we open the sidebar, we change the state of the chrome document
* This triggers an asynchronous reflow of the chrome document
** In a post-reflow callback, we adjust the size of the <browser>'s nsSubdocumentFrame's docshell
** Which resizes the contentviewer
** Which resizes the page's root widget
** Which does reflow and triggers invalidation of the right areas
*** I think this triggers a pending resize event in the child document
** Resetting the geometry the chrome document's widget for the <browser> is deferred
* Then we get an asynchronous repaint of the content document
** We set up the DC and clip region etc to draw into
** Then in nsViewManager::DispatchEvent we call WillPaint on the content presshell
** This flushes notifications, and it appears to be safe to run script so we flush out the pending resize event
** This runs a bunch of script, which happens to call some boxObject.width in the chrome document, which flushes notifications in that document
** That starts and ends a view batch in the chrome document, which triggers nsViewManager::FlushPendingInvalidates
** This flushes out the change to the geometry of the chrome document's <browser> widget, moving the widget to the right
*** This also moves the content document's window as well, of course
** Then we return out of all this and start painting into the DC we set up earlier

I think changing the ancestor widget geometry while we already have the DC set up for painting the content document confuses Windows ... which is not unreasonable.

I need to think a little about what the right fix is.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

I'm just extending the scope of the script blocker from the body of nsViewManager::Refresh to the whole NS_PAINT handler. Any script execution here has a chance of causing widget tree geometry changes that will confuse painting.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/ac60820aa423

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 411107 [details] [diff] [review]
fix

I'll take the liberty of granting myself 1.9.2 approval, since this is actually quite a bad bug and the fix is very simple.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This caused the regression in bug 527864, so I need to look into that before landing this on 1.9.2

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I actually think this should be a blocker.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1: Backout previous fix

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 2: Fire NS_WILL_PAINT on Windows

This ensures that our flushes happen before we call BeginPaint, so we end up painting the right content in the right place even if those flushes move ancestor widgets around.

This depends on the fix for bug 527864 landing.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1 v2

Correct backout

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I meant this depends on the fix for bug 517804 landing.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/ea520d552f8c
http://hg.mozilla.org/mozilla-central/rev/4e4708ca617d

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/13a1c142d014