799165 - Panes are not refreshed if their content should be changed due to selection outside of the pane (e.g. Account Settings pane and tree selection out of sync, Dom Inspector box.viewer-pane-box-1)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

STR:
1. Open Account Settings in current SM or TB nightly
2. Click Server Settings or Copies and Folders in the tree area and stay in that area with the mouse

Expected:
Pane area updates according to tree selection upon click release

Actual:
Pane area only updates upon moving the mouse outside the tree area (and, it seems, also under some less reproducible circumstances)

Regression range (provided by Hafi):
2012-09-27 19:30:00 PDT - 2012-09-28 20:38:00 PDT

Possible culprit:
Bug 539356 (part of DLBI = display-list-based invalidation)

Notes:
* This bug/regression will enter Aurora tomorrow unless fixed until then
* Feel free to move to Core/Layout or set a dependency to bug 539356 once confirmed; until now this is just a guess.

Comment 1

[:aceman]

Confirming observation, thanks for filing it. It happens for me on Win XP and Linux in the Account manager (I must click 2x to open the proper pane). But I can also observe such a slow reaction when using the DOM Inspector when switching the view mode (in the right pane), like DOM node, XBL bindings, CSS rules...

But what can we do with it in the Account manager? Should the bug be moved into Core/layout? Or do we need to adapt out code somehow?

This is observed on TB18, that will move to Aurora, but there probably will be no release from that branch.

Comment 2

[Wayne Mery (:wsmwk)]

I saw account pane nuttiness yesterday, first time. I'm using 2012-10-03 daily build on vista. In one case, the detail pane was completely blank until I navigated away from the window

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to :aceman from comment #1)
> This is observed on TB18, that will move to Aurora, but there probably will
> be no release from that branch.

SM *will* release from it. But if applications like DOMI are affected, too, it probably must be fixed in mozilla-{central,aurora} anyway.

Comment 4

[:aceman]

Yes I confirm it happens in DOM Inspector on Win XP too (switching the view mode (in the right pane), like DOM node, XBL bindings, CSS rules...).

Comment 5

[Matt Woodrow (:mattwoodrow)]

Can this be reproduced in Firefox? I don't have SM/TB builds set up.

I can't reproduce anything similar playing around with the firefox Inspector tool.

Comment 6

[:aceman]

Yes, I see it in Firefox 19a1 nightly too. But you need to inspect a xul file, e.g. chrome://inspector/content/viewers/dom/dom.xul (from File -> Inspect chrome document).

Comment 7

[Colby Russell :crussell (no longer Mozilla-ing)]

Is the observed behavior similar to this <http://screencast.com/t/r1pVbcrz>?  From bug 802711, comment 3.

Comment 8

[Ian Neal]

It seems similar to me.

Comment 9

[:aceman]

Yes, bug 802711 comment 3 is what I describe in comment 1 and comment 4.

Comment 11

[Matt Woodrow (:mattwoodrow)]

I'm not able to reproduce this on OSX (with or without hardware acceleration).

Is this correct str?

1) Install DOM Inspector - https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/
2) Open DOM Inspector window (Tools -> Web Developer -> DOM Inspector)
3) Inspect dom.xul (File -> Inspect chrome document -> chrome://inspector/content/viewers/dom/dom.xul)
4) Browse through the tree in the left panel?

I don't see anything obviously incorrect while doing that, the right panel updates correctly for me.

Comment 12

[:aceman]

No, step 4) should be:
Above the right pane, change "Object - DOM node" to "Javascript object" and do not move the mouse much. The pane will not refresh (only after you move the mouse over the location bar). If that does not reproduce, choose some other element (e.g. page) on the left, and select "Computed style", then select back to "DOM node"

Comment 13

[Matt Woodrow (:mattwoodrow)]

Awesome, I can reproduce now, thanks.

Comment 14

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't revoke the view manager flush unless we own the refresh driver

Destroying the menu popup pres shell was cancelling the refresh driver tick and stopping us from repainting the content window.

Not entirely sure why this revoke is there at all, but this is similar to the code in PresShell::Freeze().

Comment 15

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f0ca8ef31bef

Comment 16

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/f0ca8ef31bef

Comment 17

[:aceman]

Thanks a lot, it is fixed now for me on TB trunk, account managers and DOM Inspector. InvisibleSmiley, can you verify the fix on SM and mark verified?

Comment 18

[:aceman]

It does seem to cause another problem. Try clicking quickly on "Copies & folders" and then on "Composition & addressing". For a short period you'll see 
"Copies & folders" pane not fully initialized.

The way account manager in TB works is it initializes the panes in 2 stages. First it loads the xul page and then initializes some of the input elements (or hides some). In the past this operation seemed atomic and only the full result was rendered to the user. Now there is a rendering after each of these stages.

Any body has an idea if this is part of this DLBI problem or a TB specific bug connected to the way it sets up the panes?

Comment 19

[Jens Hatlak (:InvisibleSmiley)]

(In reply to :aceman from comment #17)
> InvisibleSmiley, can you verify the fix on SM and mark verified?

Verified locally (checked only the original Account Settings issue).

Note: This needs to land on Aurora, too.

Comment 20

[:aceman]

Comment on attachment 679405 [details] [diff] [review]
Don't revoke the view manager flush unless we own the refresh driver

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 539356
User impact if declined: Badly responding DOM Inspector and TB account manager.
Testing completed (on m-c, etc.): m-c + c-c trunk
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

Comment 21

[Matt Woodrow (:mattwoodrow)]

Should be very low risk, just stops us from cancelling refresh driver ticks that we need to happen. We should definitely take this for aurora.

No string or UUID changes either.

Comment 22

[bhavana bajaj [:bajaj]]

Comment on attachment 679405 [details] [diff] [review]
Don't revoke the view manager flush unless we own the refresh driver

Low risk patch for a regression in FF18.Needed on Aurora

Comment 23

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/14859729e1ab

Comment 25

[Simona Badau, Desktop QA]

Verified as fixed on Firefox 18 beta 2 - the panes are refreshed when their content should be changed due to selection outside of the pane (verified using DOM Inspector).

Verified on Windows 7, Ubuntu 12.10 and Mac OS X 10.7:
Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/20100101 Firefox/18.0

Setting the tracking flag for Firefox 18 to Verified.