Closed Bug 300095 Opened 18 years ago Closed 18 years ago

regression: Tab close button draws over top of scroll bar of first tab after closing second tab, when page has focus

Categories

(Core Graveyard :: Widget: Mac, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: waynegwoods, Assigned: mark)

Details

(Keywords: regression, Whiteboard: [CFRunLoop][no l10n impact])

Attachments

(2 files)

This appeared between the 20050621 and 20050622 Deer Park nightlies, which is
the same time as bug 298677. Whether it's related to the same CFRunLoop checkin,
I have no idea.

To reproduce:
- Ensure your preference is set to have the tab bar vanish when only one tab is open
- Open a page long enough to produce a vertical scroll bar
- Open a second tab. A blank page is fine. The tab bar pops up
- By default, the focus in the new tab is in the location bar. Click somewhere
in the blank page so that the location bar loses the focus
- Close the tab either by clicking the close button or by hitting cmd-w
- First tab should now be in the foreground and the tab bar should have
vanished, as normal. 
- Regard the top of the vertical scroll bar... an artefact consisting of the tab
close button should appear over the top of it. The scroll bar redraws properly
if you mouse over it.
Summary: regression: Tab close button draws over top of scroll bar on first tab when closing second tab when page has focus → regression: Tab close button draws over top of scroll bar of first tab after closing second tab, when page has focus
Flags: blocking1.8b4?
Keywords: regression
Whiteboard: [CFRunLoop]
FYI, the patch from bug 298677 hasn't fixed this issue.
Screenshot?
Whiteboard: [CFRunLoop] → [CFRunLoop][no l10n impact]
Here's a screen shot. Note the tab close button drawing over the top of the
scroll bar, in the position it was in the other tab before I closed it and the
tab bar was removed. The scroller doesn't have to be at the top for this to
happen.
I'm pretty sure that this was fixed in my own tree on Thursday or Friday while I
was hunting down bug 298677.  I've still got that work saved to the side, so I
should be able to resynthesize a fix.
I didn't have this fixed so much as I had it worked around.  The scrollbar's
being drawn and its rect validated before the tab bar goes away.  By not
validating or invalidating at the right moment, it'll eventually (quickly) draw
when the tab bar is gone.
By the time the validate happens, it's too late for us to really care.	Might
as well leave the rect alone, so the system can paint.	Simon thinks that
validating is a relic from the days of native form controls.
Assignee: joshmoz → mark
Status: NEW → ASSIGNED
Attachment #189863 - Flags: superreview?(sfraser_bugs)
Attachment #189863 - Flags: review?(jhpedemonte)
Attachment #189863 - Flags: superreview?(sfraser_bugs) → superreview+
With a silly little animated <textarea> with scrollbar, I don't see any extra
drawing with this patch.
Attachment #189863 - Flags: review?(jhpedemonte) → review+
Attachment #189863 - Flags: approval1.8b4?
Comment on attachment 189863 [details] [diff] [review]
Don't validate control rects

a=shaver
Attachment #189863 - Flags: approval1.8b4? → approval1.8b4+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.8b4?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.