301807 - On startup, tabbar isn't drawn

Status: VERIFIED FIXED

(Core Graveyard :: GFX: Mac, defect)

Description

[Asaf Romano (gone)]

Seen usijn: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050721 Firefox/1.0+

STR:
1) Turn off "Hide the tab bar" (Prefs->Tabs)
2) Restart the browser

-> Everything is drawn but the tabbar

If you mousehover the first tab area, part of it is drawn, the rest of the
tabbar is drawn after resize actions, etc.

probably a regression from bug 289973

Comment 1

[Simon Fraser [no longer active]]

crap

Comment 2

[Simon Fraser [no longer active]]

I can't reproduce this in my build. Also, unlikely a regression from bug 289973
because the window isn't being resized. More likely related to the various
scrollbar futzing.

Comment 3

[Asaf Romano (gone)]

Note that I first get the profile manager window (intended, of course) which
means the browser window isn't focused/active until I foucus it (known bug).

Comment 4

[Mark Mentovai]

I can reproduce what Mano's seeing.  It was caused directly by that other thing
that bug 289973 did, namely, switching from HandleUpdateEvent() directly to
Update().

Comment 5

[Gary Elshaw]

I can't reproduce with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.8b4) Gecko/20050722 Firefox/1.0+

Comment 6

[Simon Fraser [no longer active]]

(In reply to comment #4)
> I can reproduce what Mano's seeing.  It was caused directly by that other thing
> that bug 289973 did, namely, switching from HandleUpdateEvent() directly to
> Update().

I made that change because we need to do BeginUpdate/EndUpdate in response to
the kEventWindowUpdate event. It wasn't clear to me why it went through
mMacEventHandler, but maybe I changed the widget that Update was called on?

Comment 7

[Simon Fraser [no longer active]]

I still can't repro. Mano, what page loads when you start the browser? Does it
happen if the profile manager doesn't show first?

Comment 8

[Asaf Romano (gone)]

<Shrung/> I can't reproduce it anymore...

Mark, could you check those details in your build (assuming you're still able to
reproduce it)?

Comment 9

[Mark Mentovai]

I see it both in the official nightly and a couple of my own builds.  On a fresh
profile, clear the hide-when-only-one-tab preference and set your home page to
about:blank.  Quit and launch again from the command line with a -profilemanager
argument to ensure that the app starts backgrounded after you select a profile.

If you've got a home page set, all of that extra drawing is probably reviving
the tab bar.

Comment 10

[philippe (part-time)]

I experienced the same problem while upgrading to the 0725 build. On first
launch, the browser loads with the default theme (I use a custom theme), and
with the tab bar invisible.
At first, I thought bug 301872 was back, but that is not the case.

When checking the Theme Manager window, the tabbar started painting - not fully,
mind you. In my set up, that window is positioned partly over the browser chrome.
Restarting the browser, and 1/ my custom theme was in use and 2/ no problems
with the tabbar.

Preferences:
about:blank as home page
tabbar: always visible.

Comment 11

[Simon Fraser [no longer active]]

I can repro now.

Changing the carbon event handler back to
  self->mMacEventHandler->UpdateEvent();
from
  self->Update();
which has the effect of bypassing BeginUpdate/EndUpdate results in lots more
full-window redraws, which is slower (but causes the tab bar to draw).

What's odd is that if I log the invalidate calls made on the window, I don't see
one that corresponds to the tab bar area. I need to debug some more.

Comment 12

[Simon Fraser [no longer active]]

Ah, this is the "invalidate inside a paint" striking Carbon widget. It's also a
race; if I debug or turn on paint flashing then it doesn't happen.

Comment 13

[Simon Fraser [no longer active]]

Attachment: Patch

The bug was that there was code in nsWindow::Update() that assumed that the
region redrawn by gecko would not need to be drawn again, so is validated. This
clobbered any changes made to the update region during drawing (by
invalidatation).

The new strategy is to subtract the drawn region from the old update region
(thus preserving dirty areas outside of gecko), and invalidate it, which adds
to (rather than replacing) the new update region.

Comment 14

[Mark Mentovai]

Comment on attachment 190661 [details] [diff] [review]
Patch

What's going on with postUpdateRgn?

Comment 15

[Simon Fraser [no longer active]]

postUpdateRgn is unused; I should remove it.

Comment 16

[Simon Fraser [no longer active]]

Attachment: Updated patch

Comment 17

[Mark Mentovai]

Comment on attachment 190668 [details] [diff] [review]
Updated patch

Makes sense.  I like.

Comment 18

[Simon Fraser [no longer active]]

Checked in.