348759 - [Mac] Shadow missing around favicon in location bar

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

[Mark Mentovai]

This only happens sometimes, and I can't reproduce it on command, but I do see it often.  Sometimes, the leftmost part of the location bar around the favicon loses its shadow.  This began when the new theme landed.  I mentioned this problem in bug 347468 comment 1 and bug 348758 comment 1.

Comment 1

[Mark Mentovai]

Attachment: Fig. 1. Present appearance

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Mark, can you reproduce this in nightlies? I'm not seeing it right now ... or is this a "only sometimes sorta thing"? Renominate if you're still seeing it.

Comment 3

[Mark Mentovai]

Yeah, I saw it again in today's build, about 20 minutes ago.

Comment 4

[Dietrich Ayala (:dietrich)]

Attachment: Fig. 2. Extending beyond favicon

I've seen this extending beyond the favicon area. This is an "occurs sometimes" bug.

Comment 5

[Mark Mentovai]

I'm able to reproduce consistently by hovering between the home button (immediately to the left of the location bar) and whatever bookmark happens to be in the toolbar below.  In Fig. 1, this would be moving the mouse quickly between the home button and the Latest Headlines livemark.  After moving the mouse like this a few times, part of the location bar's shadow disappears.

Comment 6

[Drew D. Saur]

Attachment: Fig. 3. Munged address bar

I have noticed that related behavior that stems from Flash content being scrolled up and essentially "underneath" the address bar. See my attachment (Fig. 3) taken from dpreview.com.

Comment 7

[Drew D. Saur]

Just to confirm - this is 100% reproducible with any Flash content that is scrolled up and "underneath" the address bar.

Comment 8

[Dietrich Ayala (:dietrich)]

Attachment: test case

STR:

1. scroll until the flash movie is behind the URL bar, using either arrows, or mouse. (if you scroll w/ the mouse, you bug will occur when the mouse button is released)

Expected results: The URL bar's shadow should remain visible.

Actual results: The URL bar's shadow disappears where the flash movie is, or has been.

Notes:

- The effect does not go away after moving the flash movie away from the URL bar. Only reloading, or navigating away fixes it.

- The effect can be partial: If you scroll the flash movie only halfway under the URL bar, only the bottom shadow disappears.

Comment 9

[Dietrich Ayala (:dietrich)]

Another test case, but with quicktime:

http://www.apple.com/getamac/

Start playing one of the videos, then do the same scroll steps detailed in the previous comment.

This indicates that the bug might affect plugins generally, not just flash.

Comment 10

[Dietrich Ayala (:dietrich)]

(In reply to comment #5)
> I'm able to reproduce consistently by hovering between the home button
> (immediately to the left of the location bar) and whatever bookmark happens to
> be in the toolbar below.  In Fig. 1, this would be moving the mouse quickly
> between the home button and the Latest Headlines livemark.  After moving the
> mouse like this a few times, part of the location bar's shadow disappears.
> 

I can reproduce the bug using these steps now, which indicates that the problem is not plugin-specific. The key for reproducing using these steps is to use a livemark. I was not able to reproduce the problem using these steps when testing with regular bookmark.

Comment 11

[Dietrich Ayala (:dietrich)]

Attachment: test case w/ search bar

I've updated the testcase to include another instance of the flash movie, this time underneath the search bar. It seems that the presence of the flash movie
behind the search bar darkens (or bolds) the font of the search engine name.
That might be a separate bug though.

Comment 12

[Dietrich Ayala (:dietrich)]

Attachment: tab text distortion on trunk

Removing the deck hack in browser.xul fixes the URL bar problem:

http://lxr.mozilla.org/mozilla1.8/source/browser/base/content/browser.xul#216

After removing the <deck> and the extra <textbox>, I was not able to reproduce the bug in the URL bar.

However, the deck hack itself is likely not the root cause of the problem, as the bug manifests itself in the search box as mentioned previously. Also, on trunk neither the search box or URL bar have the problem. Instead, there's distortion on the tab text immediately outside the flash movie, as shown in the attached screenshot.

Comment 13

[Dietrich Ayala (:dietrich)]

I'm at a loss to find out what's causing this bug. It seems like this must be lower level than theme changes. Does anyone else have any ideas as to what's causing this bug?

Comment 14

[Mike Connor [:mconnor]]

Mark, do you know who would be the best person to follow up here?

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

We really, really need some people to dig in here. Josh, any ideas?

Comment 16

[Mark Mentovai]

Ccing jhpedemonte, who's worked with gfx/src/mac, and roc, who knows everything.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

MY guess is that the text problem on trunk is due to text drawing not being clipped properly to the damage rect.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A reduced testcase would really help for the favicon problem, but I understand that that's hard to do here.

Comment 19

[Asaf Romano (gone)]

So, I'm pretty sure this is a regression from bug 337427, and not from the VR. That bug isn't easily backoutable(tm) though. I will manually back it out later today and come back with results.

Assigning to myself for investigation.

Comment 20

[Asaf Romano (gone)]

As expected, I can't reproduce this after getting rid of the xul deck.

Comment 21

[Asaf Romano (gone)]

Attachment: Patch

Someone should go ahead and file a bug on the core issue. Using a stack here is the right thing (as much as "right thing" could be said on the entire hack used here) since it's less expensive layout/widget wise.

With that said, after some time I could reproduce this once (with the flash testcase only), but do note scrolling again reintroduced the shadow (this is very different from what happens now). I'm pretty sure I've seen this issue (with plugins involved) in 1.5 too, so I would like to get this on branch and see if this really fixes the "new" part of this bug (which is hard to reproduce).

Comment 22

[Mike Connor [:mconnor]]

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

hmm, <stack> makes so much more sense here too.  I think the core issue can still affect this, but that'll be ok enough.

Comment 23

[Asaf Romano (gone)]

1.8 branch:
mozilla/browser/base/content/browser.xul  1.268.2.63
mozilla/toolkit/content/widgets/autocomplete.xml 1.44.2.17

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This bug doesn't exist on trunk so I think we're not really going to fix it on branch.

The trunk Mac text bug should be filed separately

Comment 25

[Asaf Romano (gone)]

trunk:
mozilla/browser/base/content/browser.xul 1.319
mozilla/toolkit/content/widgets/autocomplete.xml 1.68