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.

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

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

Setting QA Contact/component.

reassigning to german for triage.

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

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

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

*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to jrgm@netscape.com

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

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?

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.

Mass-adding beta2 keyword to all skins bugs.

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.

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

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

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 on attachment 648948 [details] [diff] [review] Bug 18581 - 780351 - Tests for mozbrowser acting as a window name namespace barrier. Sorry, wrong bug!