18581 - Part of new skin does not redraw properly

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[endah]

The two little 'light-blue' down arrows on the new skin (next to the navigation
toolbar and personal toolbar), when moved over, redraw as light grey colour (no
image - flat colour). Unfortunately I can only guess that this is not the way it
is meant to work - so apologies if it's intended this way, but I imagined it was
intended to retain the arrows, but in a different colour.

This has occurred in all builds I've tried since the new skin appeared. This
includes source downloads from 1st Nov and 10th Nov.

Comment 1

[larry]

I couldn't reproduce this on 1999111017 Linux, Redhat 6.0

Comment 2

[larry]

Wait, no... sorry...
i know what you mean now.
I agree...
There probably should be something there other than
plain grey.

Comment 3

[leger]

Setting QA Contact/component.

Comment 4

[Peter Trudelle]

reassigning to german for triage.

Comment 5

[german]

I cannot reproduce this problem. Can you please attach a screenshot. Thanks!

Comment 6

[Paul MacQuiddy]

spam: changing qa contact from ckritzer -> paulmac for xul bugs

Comment 7

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.

Comment 8

[Paul MacQuiddy]

*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to
[e-mail]

Comment 9

[Peter Trudelle]

Adding 'skins' keyword to appropriate bugs en masse, sorry about any 
mistakes...

Comment 10

[Peter Trudelle]

Should this bug be targetted for M16 as part of the skinnability push for B2?  
Could you please set the target so we know whether to expect it?

Comment 11

[german]

Still cannot reproduce the problem. Works for me on both Win32 and MacOS using
build 2000040521. What you are talking about sounds like the appropriate
mouseover bitmap (which reverses colors, so that you have a d'blue triangle on a
light teal background) is not loading on hover, hence the plain grey toolbox
background color shines through. Again, I do not see this problem - it works for me.

Comment 12

[Peter Trudelle]

Mass-adding beta2 keyword to all skins bugs.

Comment 13

[John Morrison]

German -- I can see this, but only on winNT (testing with 2000040609 binaries 
on winNT and win2k), but it's a very subtle event problem (I think).

1) Move the mouse over the Bookmarks <titledbutton>
2) now move the mouse to the left over the toolbar grippy -- the :hover state
   style is applied.

3) move the mouse back over the HTML content area

4) repeat 1&2 -- _this_ time (and every subsequent time) the :hover
   list-style-image is not loaded. 

Note, however, that if you mouseover the grippy from anywhere but the bookmark
titledbutton, the :hover will work. It is _only_ on the transition between
the two :hover styles (bookmarks then grippy) that fails to load the image.

Comment 14

[leger]

event based -> toolkit team?
I don't think this is a gate keeper for skinnability.

Comment 15

[Peter Trudelle]

This sounds like deeper infrastructure, reassigning to joki for triage, cc 
pierre.

Comment 16

[John Morrison]

This event problem seems to have gone away -- checking with 2000041309 on win2k
(and on yesterday's build), the :hover state for the toolbar grippy is painted
each and every time a mouseover occurs. Marking WORKSFORME.

Comment 17

[Justin Lebar (not reading bugmail)]

Attachment: Bug 18581 - 780351 - Tests for mozbrowser acting as a window name namespace barrier.

Comment 18

[Justin Lebar (not reading bugmail)]

Comment on attachment 648948 [details] [diff] [review]
Bug 18581 - 780351 - Tests for mozbrowser acting as a window name namespace barrier.

Sorry, wrong bug!

Comment 19

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/b75583c5a863
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18581 ETP Standard option is truncated (https://github.com/mozilla-mobile/fenix/pull/18586)