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
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
FYI, the patch from bug 298677 hasn't fixed this issue.
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.
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+
Comment on attachment 189863 [details] [diff] [review] Don't validate control rects a=shaver
Attachment #189863 - Flags: approval1.8b4? → approval1.8b4+
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.