Tooltip showing incorrectly since landing of DBLI

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Assigned: mattwoodrow)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18+ fixed)

Details

Attachments

(1 attachment)

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

5 years ago
OS: Windows 7 → All
Hardware: x86_64 → All

Comment 1

5 years ago
Probably dupe of Bug 770052?
tracking-firefox18: --- → ?
(Assignee)

Comment 2

5 years ago
Created attachment 666275 [details] [diff] [review]
Make sure we schedule paint for popups.

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)
(Assignee)

Updated

5 years ago
Duplicate of this bug: 795653
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+
Blocks: 795619
Blocks: 795577
Blocks: 770572
(Assignee)

Comment 5

5 years ago
https://hg.mozilla.org/mozilla-central/rev/8cc407a142e8
Blocks: 770144
No longer blocks: 770144
Blocks: 770052
Blocks: 795679
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 770572
Duplicate of this bug: 770052
Duplicate of this bug: 795619
Duplicate of this bug: 795577
Duplicate of this bug: 795679

Updated

5 years ago
tracking-firefox18: ? → +

Updated

5 years ago
Assignee: nobody → matt.woodrow

Updated

5 years ago
status-firefox18: --- → fixed
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.