Closed
Bug 795576
Opened 12 years ago
Closed 12 years ago
Tooltip showing incorrectly since landing of DBLI
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: jmjjeffery, Assigned: mattwoodrow)
References
Details
(Keywords: regression)
Attachments
(1 file)
1.43 KB,
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
Wrong tooltips are showing, looks like a reflow problem maybe.
STR:
1. Click Nightly/Firefox button
2. Hover over 'Save Page as...'
3. Hover over 'Full Screen' NOTE: Cut-off CTRl box from the step above
4. Hover over 'Save Page as... ' again, NOTE: F11
Do above steps without closing the Menu..
Intermittently mousing outside the Menu and back in will properly 'refresh' the tooltip, most times it stays showing wrong tooltip.
Updated•12 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Comment 1•12 years ago
|
||
Probably dupe of Bug 770052?
Updated•12 years ago
|
tracking-firefox18:
--- → ?
Assignee | ||
Comment 2•12 years ago
|
||
When walking up the frame tree add invalid flags, we were walking right past popups (display roots) and not noticing.
We could then not end up setting the 'can't do an empty transaction' flag on the popup display root, and we'd never actually paint anything new.
Attachment #666275 -
Flags: review?(roc)
Comment on attachment 666275 [details] [diff] [review]
Make sure we schedule paint for popups.
>diff --git a/layout/generic/nsFrame.cpp b/layout/generic/nsFrame.cpp
>--- a/layout/generic/nsFrame.cpp
>+++ b/layout/generic/nsFrame.cpp
>@@ -4765,27 +4765,31 @@ nsIFrame::GetTransformMatrix(const nsIFr
>
> static void InvalidateFrameInternal(nsIFrame *aFrame, bool aHasDisplayItem = true)
> {
> if (aHasDisplayItem) {
> aFrame->AddStateBits(NS_FRAME_NEEDS_PAINT);
> }
> nsSVGEffects::InvalidateDirectRenderingObservers(aFrame);
> nsIFrame *parent = nsLayoutUtils::GetCrossDocParentFrame(aFrame);
>+ bool needsSchedulePaint = false;
> while (parent && !parent->HasAnyStateBits(NS_FRAME_DESCENDANT_NEEDS_PAINT)) {
> if (aHasDisplayItem) {
> parent->AddStateBits(NS_FRAME_DESCENDANT_NEEDS_PAINT);
> }
>+ if (nsLayoutUtils::IsPopup(parent)) {
>+ needsSchedulePaint = true;
>+ }
Add a comment here describing why we do this.
r=me with that. Oh, the continual travails of not reftesting popup widgets ... :(
Attachment #666275 -
Flags: review?(roc) → review+
Assignee | ||
Comment 5•12 years ago
|
||
Confirmed fixed in http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1348986078/firefox-18.0a1.en-US.linux-x86_64.tar.bz2 . This should be in the next nightly.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Updated•12 years ago
|
Assignee: nobody → matt.woodrow
Updated•12 years ago
|
status-firefox18:
--- → fixed
Comment 12•12 years ago
|
||
I'm not able to reproduce the issue on a Nightly from 2012-09-29.
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20120929191424
These are the STR that I use:
1. Open Nightly
2. Hover over 'Save Page as...' and stay there for 1 minute
3. Hover over 'Full Screen' (from View -> Full Screen) and stay there for 1 minute
4. Hover over 'Save Page as... ' again
After doing each of the steps 2, 3 and 4, I can't see any tooltip showing.
Any suggestions would be appreciated.
You need to log in
before you can comment on or make changes to this bug.
Description
•