Tab switcher leaves drawing turds on the UI

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: bz, Assigned: mstange)

Tracking

(Blocks: 1 bug, {verified1.9.1, verified1.9.2})

Trunk
mozilla1.9.3a1
verified1.9.1, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 +
wanted1.9.2 +
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta1-fixed, status1.9.1 .6-fixed)

Details

(URL)

Attachments

(1 attachment)

STEPS TO REPRODUCE:

1)  Open 9 tabs with http://web.mit.edu in them
2)  Open 1 tab with http://www.mozilla.org in it
3)  Position your Firefox window so that when the tab switcher comes up its
    search field is over your tabstrip (or really, any part of your chrome).
    This requires that the window not be maximized.
4)  Click the tab switcher button.
5)  Type "moz" in the search field in the tab switcher.
6)  Hit the Escape key twice.

ACTUAL RESULTS: Tab switcher is dismissed, but its search field is still show over the chrome.  Dragging the window off screen and back doesn't help.  Moving focus out of it does.

EXPECTED RESULTS: No turds left over when the tab switcher is dismissed.

ADDITIONAL INFORMATION: There's a bit of jitter when going from 2 pages to 1 and back in the switcher.  If that transition doesn't happen, the bug doesn't appear.
dupe of bug 463574? (see bug 461519 which was duped to said bug).
Looks possible, though this one is a lot clearer in terms of reproducing.  I'll mark dependent for now, and figure that vlad and Dão will sort it out.
Depends on: 463574
Yeah, this is better. Requesting blocking1.9.2 so that bug 463574 can be duped against this one...
Component: General → GFX
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All

Updated

9 years ago
Flags: blocking1.9.2?
see also bug 445404
Version: unspecified → Trunk
Product: Core → Core Graveyard

Updated

8 years ago
Component: GFX → Layout: View Rendering
Product: Core Graveyard → Core
QA Contact: general → layout.view-rendering

Updated

8 years ago
Blocks: 505404

Updated

8 years ago
No longer depends on: 463574
Duplicate of this bug: 463574

Updated

8 years ago
Duplicate of this bug: 505658
Duplicate of this bug: 505749

Updated

8 years ago
(Assignee)

Comment 8

8 years ago
Where is the code that prevents frames in a popup window from getting into the parent window's display lists?
Frames that have popup frame children just shouldn't traverse those children in their BuildDisplayList implementation.

As far as I can tell, that's true in nsPopupSetFrame.
(Assignee)

Comment 10

8 years ago
I don't see where nsPopupSetFrame overrides BuildDisplayList.
nsBoxFrame::BuildDisplayList doesn't walk the popup list, though.
Don't the steps-to-reproduce involve enabling the tab switcher?  How does one do that?
The prefs are browser.ctrlTab.previews and browser.allTabs.previews.
Only browser.allTabs.previews seems to be relevant here.

Unfortunately the STR are still more complicated...
If you have DOMi, select the browser window, find the element with the "allTabs-panel" id and add the class attribute with "KUI-panel" as the value. After that, see comment 0.
Flags: blocking1.9.2? → wanted1.9.2+
(In reply to comment #14)
> Unfortunately the STR are still more complicated...
> If you have DOMi, select the browser window, find the element with the
> "allTabs-panel" id and add the class attribute with "KUI-panel" as the value.

Or uncomment line 260:
http://hg.mozilla.org/mozilla-central/annotate/94cd140316fb/browser/base/content/browser.xul#l257
(Assignee)

Comment 16

8 years ago
(In reply to comment #11)
> nsBoxFrame::BuildDisplayList doesn't walk the popup list, though.

But the panel's placeholder frame is in the mFrames list of the popup set frame, and that gets replaced by the real panel frame in nsIFrame::BuildDisplayListForChild.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Hmm. Indeed! Then we should override BuildDisplayList in nsPopupSetFrame and have it do nothing.
(Assignee)

Comment 18

8 years ago
Created attachment 399010 [details] [diff] [review]
v1

Overriding BuildDisplayList in nsPopupSetFrame won't be enough since popups aren't necessarily contained in a popupset. So I'm blocking them in nsIFrame::BuildDisplayListForChild.

GetType() == nsGkAtoms::menuPopupFrame seems to be the common way of identifying popup frames; I don't think we need a new IsPopup() method.

A little background info on this bug for those playing along at home:
The placeholder frames I mentioned in comment 16 are usually not harmful because they're 0x0 sized, so they don't intersect the dirty rect. That means that under normal circumstances they're not included in the display list -- except if NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO is set on them. And one thing that causes this flag to be set is the caret. So it was in fact the textbox in the panel that triggered this bug.
Attachment #399010 - Flags: review?(roc)
(Assignee)

Updated

8 years ago
Duplicate of this bug: 445404
Attachment #399010 - Flags: review?(roc) → review+
(Assignee)

Comment 20

8 years ago
http://hg.mozilla.org/mozilla-central/rev/f8ee121bd0e1
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Assignee)

Updated

8 years ago
Attachment #399010 - Flags: approval1.9.2?
Attachment #399010 - Flags: approval1.9.1.4?
(Assignee)

Comment 21

8 years ago
Comment on attachment 399010 [details] [diff] [review]
v1

Requesting branch approval: tiny, risk-free fix with test
Attachment #399010 - Flags: approval1.9.1.4? → approval1.9.1.5?
Attachment #399010 - Flags: approval1.9.2? → approval1.9.2+
(Assignee)

Comment 22

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a8f78c8925ef
status1.9.2: --- → beta1-fixed
Verified fixed on trunk and 1.9.2 with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090922 Minefield/3.7a1pre ID:20090922030618

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre ID:20090922041132
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
Keywords: verified1.9.2
Transferring blocking from bug 463574 (though already fixed).
Flags: blocking1.9.2+
Comment on attachment 399010 [details] [diff] [review]
v1

Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #399010 - Flags: approval1.9.1.5? → approval1.9.1.5+
(Assignee)

Comment 26

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b67fcb2d3fe5
status1.9.1: --- → .5-fixed
Blocks: 465076
I can't repro the original problem on 1.9.1.5 (pre-fix) with Dao's control-tab addon (https://addons.mozilla.org/en-US/firefox/addon/5244) on Windows XP. Does this bug repro on 1.9.1 or are we just changing the code in all branches?
Speaking to Henrik, it turns out that he could only repro this on OS X. So I tried there and could repro it in 1.9.1.5 and see the fix with the nightly 1.9.1 build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.6pre) Gecko/20091125 Shiretoko/3.5.6pre).
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.