831160 - Switching between active/inactive causes toolbar/statusbar to not repaint properly

Status: RESOLVED FIXED

(SeaMonkey :: OS Integration, defect)

Description

[Andrea Govoni]

If I click outside an active (foremost) SeaMonkey browser window, only the title bar gets the inactive gradient. If I then move my mouse over the URL bar or over a launch icon in the left side of the status bar, the tool bar and the status bar get the correct background.
I'm seeing the issue also in the other way. If I click inside an inactive browser window, only the title bar gets the active gradient. Then when I move the mouse over a text field, a tab or an area that make the pointer change its shape, the tool bar and the status bar get the correct background.
I've already reported this in bug 626096, comment 30 some days ago but then I concluded that it seems a different issue and I feel a new bug specifically targeted to SeaMonkey will be easier to note and find by searches. If I'm wrong please close this bug as a dupe.
I'm experiencing this bug since I installed SeaMonkey 2.15. It was not present in SeaMonkey 2.14.1. SeaMonkey 2.16 Beta 1 doesn't solve the issue and I cannot reproduce it with Firefox 18.0.
My system is a Mac mini Server (Middle 2010) with Mac OS X 10.7.5 (11G63). This model comes with an NVIDIA GeForce 320M 256 MB graphic card and I'm seeing the problem with hardware acceleration on and off.

Comment 1

[Trane Francks]

Verified with SeaMonkey 2.15 on OS X 10.6.8 on mid-2007 MacBook2,1 (GMA 950). Behaviour was not seen in any earlier versions of SeaMonkey.

Comment 2

[Philip Chee]

Are you using the SeaMonkey default theme or the Modern theme?

Comment 3

[Trane Francks]

Attachment: Screenshot of repaint problem on Snow Leopard w. SM 2.15.

Comment 4

[Trane Francks]

I'm using the default theme. The Modern theme is disabled.

Comment 5

[Stefan [:stefanh]]

My best guess is that this is a core issue - probably obscured in Firefox by css.

Comment 6

[Andrea Govoni]

@Philip Chee on comment 2
I'm using the default theme. I've just tried the Modern theme but it's impossible to see the issue with it cause it does not have a unified toolbar and a status bar that change their appearance along with the window active/inactive status.

@Stefan on comment 5
Please tell me how to remove the CSS stuff from Firefox and I'll be happy to perform the test.

Comment 7

[Stefan [:stefanh]]

(In reply to Andrea Govoni from comment #6)
> @Stefan on comment 5
> Please tell me how to remove the CSS stuff from Firefox and I'll be happy to
> perform the test.

If you build yourself, you can just remove the -moz-window-inactive rules in browser.css. If you don't, you'll have to edit the theme files inside the Firefox.app. package (I'd have to look into it, since I think the structure there have changed since I last hacked those files). The odd part here is that you havent seen this before 2.15.

We could try to work-around the issue in SeaMonkey by adding a bunch of -moz-window-inactive rules (as I suggested in bug 626096) to the relevant elements.

Comment 8

[Andrea Govoni]

(In reply to Stefan [:stefanh] from comment #7)
> If you build yourself, you can just remove the -moz-window-inactive rules in
> browser.css.

Unfortunately I don't build Firefox from sources right now.

> If you don't, you'll have to edit the theme files inside the
> Firefox.app. package (I'd have to look into it, since I think the structure
> there have changed since I last hacked those files).

I lurked the Firefox application bundle a lot but I cannot find anything containing the -moz-window-inactive string to edit.

> The odd part here is
> that you havent seen this before 2.15.

Do you want me to try all the released 2.15 betas?
Perhaps it could help to refine the time range when the culprit change has been introduced.

> We could try to work-around the issue in SeaMonkey by adding a bunch of
> -moz-window-inactive rules (as I suggested in bug 626096) to the relevant
> elements.

But it would be just a workaround, as you said… wouldn't be much better to solve the issue at the roots? :)

Comment 9

[Stefan [:stefanh]]

(In reply to Andrea Govoni from comment #8)
> > The odd part here is
> > that you havent seen this before 2.15.
> 
> Do you want me to try all the released 2.15 betas?
> Perhaps it could help to refine the time range when the culprit change has
> been introduced.

Yeah, if you have the time - that would help. We would need a regression-window of one day in order to find the patch that caused this, so you'll need to test the 2.15a nightlies (ftp.mozilla.org/pub/seamonkey/nightly/2012/10/). What might have happened is that something made bug 626096 manifests itself again (it could of course also be a new issue with the same symptoms as in bug 626096 - graphic issues are tricky).


> > We could try to work-around the issue in SeaMonkey by adding a bunch of
> > -moz-window-inactive rules (as I suggested in bug 626096) to the relevant
> > elements.
> 
> But it would be just a workaround, as you said… wouldn't be much better to
> solve the issue at the roots? :)

Of course, but since it's only SeaMonkey that seems to be hit (bug 626096 have been around for 2 years), it's not likely that this will be treated as a high-priority-issue.

Comment 10

[Stefan [:stefanh]]

(In reply to Andrea Govoni from comment #8)
> (In reply to Stefan [:stefanh] from comment #7)
> > If you build yourself, you can just remove the -moz-window-inactive rules in
> > browser.css.
> 
> Unfortunately I don't build Firefox from sources right now.
> 
> > If you don't, you'll have to edit the theme files inside the
> > Firefox.app. package (I'd have to look into it, since I think the structure
> > there have changed since I last hacked those files).
> 
> I lurked the Firefox application bundle a lot but I cannot find anything
> containing the -moz-window-inactive string to edit.

Actually, we don't need to test this since you see it in DOMi and we know that a repaint is triggered with the inactive style rules (that DOMi and SeaMonkey lacks). What's interesting here is that you started seeing this in 2.15.

Comment 11

[Stefan [:stefanh]]

FWIW, I see this too in 2.15, but slightly different. The elements seem to repaint properly, but it's a slight lag of 1 sec or so. This is with a mid-2011 mini (Intel HD 3000 graphics). A quick test reveals that I don't see the problem in 2.14.

Comment 12

[Stefan [:stefanh]]

(In reply to Stefan [:stefanh] from comment #9)

> > Do you want me to try all the released 2.15 betas?
> > Perhaps it could help to refine the time range when the culprit change has
> > been introduced.
> 
> Yeah, if you have the time - that would help. We would need a
> regression-window of one day in order to find the patch that caused this, so
> you'll need to test the 2.15a nightlies
> (ftp.mozilla.org/pub/seamonkey/nightly/2012/10/). 

Huh, not many mac builds there...

Comment 13

[Stefan [:stefanh]]

FWIW, I've found a regression window by testing firefox builds: the problem first appears in the mac build in ftp://ftp.mozilla.org/pub/firefox/nightly/2012/09/2012-09-28-03-05-44-mozilla-central/

I'll now try to find the patch that caused this. Most likely, we'll need to file a new bug for this.

Comment 14

[Stefan [:stefanh]]

Andrea,

Can you confirm my regression date in Firefox? I think I was wrong in my last comment - that folder contains the last good one...

Comment 15

[Andrea Govoni]

(In reply to Stefan [:stefanh] from comment #14)
> Can you confirm my regression date in Firefox? I think I was wrong in my
> last comment - that folder contains the last good one...

Confirmed, the last good Firefox build is
ftp://ftp.mozilla.org/pub/firefox/nightly/2012/09/2012-09-28-03-05-44-mozilla-central/
and the first one that contains the bug is
ftp://ftp.mozilla.org/pub/firefox/nightly/2012/09/2012-09-29-03-06-24-mozilla-central/.

As you said, there aren't many SeaMonkey Mac builds to test against, but I suppose that the Firefox regression window we found is enough.
Sorry for the late reply.

Comment 16

[Stefan [:stefanh]]

Thanks. I thought it was better to file a new bug instead of moving this to core, so I filed bug 833033 where I summarized everything.

Comment 17

[Andrea Govoni]

Bug 833033 has been marked RESOLVED.

I verified this bug is fixed in this SeaMonkey 2.18a1 build:
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2013-02-04-00-30-10-comm-central-trunk/seamonkey-2.18a1.en-US.mac.dmg

With this SeaMonkey 2.17a2 build I can still reproduce the problem, though:
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2013-02-04-01-30-07-comm-aurora/seamonkey-2.17a2.en-US.mac.dmg

Does it mean that we have to wait SeaMonkey 2.18 to see this issue addressed?

Comment 18

[Stefan [:stefanh]]

(In reply to Andrea Govoni from comment #17)

> Does it mean that we have to wait SeaMonkey 2.18 to see this issue addressed?

Since the patch in bug 833033 only landed on trunk (at that time it was Mozilla 21), yes.

Comment 20

[Tony Mechelynck [:tonymec]]

IIUC, comment #17 witnessed the bug fixed in SeaMonkey 2.18 or later by mozilla-central changeset ab658aec6a28