361903 - [suiterunner] Personal Toolbar expands when items are hovered

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Stefan [:stefanh]]

If you hover over an item (link) in the Personal Toolbar, the height and/or width of the toolbar increase. I have only tested this on Mac Classic - in my case the toolbar's height increases. Mark (Linux?), on the other hand, told me that for him the toolbar expands horisontally.

Comment 1

[Tobias Fischer]

Using the tpol Windows-Builds (al Moment 2006120402) with Classic-Theme, the PTB will incresae in width and hight by something about 2 or 3 Pixel while hoovering the Buttons. 
Only the "Bookmarks"-Button will not show this effect, the higth and width of the PTB will be unchanged when I hoover this one. But this one is also the only Button that will show the 3D-Effect with mouseover. 

This effect was missing at all other Buttons.

Comment 2

[Stefan [:stefanh]]

You can actually overrule this behaviour by manipulating padding/margin etc of .bookmark-item:hover.

Comment 3

[Robert Kaiser]

Attachment: patch v1: always use 2px border on bookmark items

The problem comes from a broder size mismatch between xpfe and toolkit toolbarbuttons (toolkit uses 1px borders, xpfe has 2px borders).
As we're depending on 2px borders of those bookmark items in other definitions below (esp. d&d), I'm setting all bookmark items in the toolbar to 2px borders with this patch.
This satifies suiterunner and should not change anything for xpfe SeaMonkey (couldn't test there because I have a patch in my tree that brakes xpfe browser atm).

Comment 4

[[e-mail]]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

Doesn't Mnyromyr's toolbar patch fix this? (Except it has its own bugs, but...)

Comment 5

[[e-mail]]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

Or maybe I've got Standard8's toolbar patch applied that fixes is...

Comment 6

[[e-mail]]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

Or maybe it's Standard8's toolbar patch I've applied that fixes it...

Comment 7

[Robert Kaiser]

Oh, hmm, as the patch for bug 361159 uses a different toolbarbutton.css, it may fix it...
I'm not even sure if that use of a different toolbarbutton.css there is even a good idea though, I guess I need to dig deeper into that...

Comment 8

[[e-mail]]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

Because bug 361159 fixes this.

Comment 9

[Robert Kaiser]

If my new patch on bug 361159 is taken, we need this simple fix again.

Comment 10

[Robert Kaiser]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

re-request review because we need it again with the new patch of bug 361159 (which doesn't override toolkit's toolbarbutton.css)

Comment 11

[[e-mail]]

Comment on attachment 254162 [details] [diff] [review]
patch v1: always use 2px border on bookmark items

Ah yes, I remember the problem I had now; the bookmarks button and bookmark folder toolbarbutton borders are messed up with this patch.

Comment 12

[Robert Kaiser]

Attachment: patch v2: use 2px border only on non-container bookmark items

This is better. We only need that 2px border on non-container bookmark items, so we only need to set it there. Containers (menubuttons) can stay with the 1px border *stripe uses there.

Comment 13

[[e-mail]]

Comment on attachment 255792 [details] [diff] [review]
patch v2: use 2px border only on non-container bookmark items

OK, so the problem here is that the bookmarks toolbar is a different height if you hide the Home button and remove all the non-folder bookmarks.

Comment 14

[[e-mail]]

Comment on attachment 255792 [details] [diff] [review]
patch v2: use 2px border only on non-container bookmark items

Also drop feedback before/after personal toolbar bookmark folders doesn't work with this patch.

Comment 15

[Georg Maaß]

Suiterunner Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a3pre) Gecko/2007022008 SeaMonkey/1.5a (downloaded from 
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/phlox-trunk/) has this bug too. It occures each time a link in the personal toolbar is underlined by the hover style. This also causes a complete redraw of the document window.

Comment 16

[Stefan [:stefanh]]

(In reply to comment #15)
> Suiterunner Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
> en-US; rv:1.9a3pre) Gecko/2007022008 SeaMonkey/1.5a (downloaded from 
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/phlox-trunk/)
> has this bug too.It occures each time a link in the personal toolbar is
> underlined by the hover style.

For some reason I can't reproduce this anymore (2007022200 phlox build).

>This also causes a complete redraw of the
> document window.

That might be bug 361600 - a regression from the switch to cairo.

Comment 17

[Stefan [:stefanh]]

 
> For some reason I can't reproduce this anymore (2007022200 phlox build).

I was wrong, I see it on my trunk debug build

Comment 18

[Robert Kaiser]

Attachment: patch v3: don't touch border width at all

This approach resolves this by simplifying the definitions to just reuse the default border width, only defining colors (and style).
This also make drag & drop feedback use simple CSS border-color, which looks fine with the 1px border of toolkit and should look well enough for xpfe.
On suiterunner, this looks and works fine for me, I couldn't test xpfe as that seems to have broken personal toolbar on my build even without this patch.

Comment 19

[Stefan [:stefanh]]

Comment on attachment 260128 [details] [diff] [review]
patch v3: don't touch border width at all

Hmm, I tested this on mac classic (pretty clean suiterunner source) and I don't see any change. The PT still expands vertically when I hover over "Home" and my bookmarks.

Comment 20

[[e-mail]]

Comment on attachment 260128 [details] [diff] [review]
patch v3: don't touch border width at all

Well, it works on suiterunner but it busts xpfe pretty badly... you should be able to fix xpfe by changing border-XXX-color: ThreeDDarkShadow; to -moz-border-XXX-colors: ThreeDDarkShadow transparent; and fix border-color: transparent !important; by reverting the border colour changes (also do you need the border style change?)

Comment 21

[Stefan [:stefanh]]

(In reply to comment #20)
> (From update of attachment 260128 [details] [diff] [review])
> Well, it works on suiterunner but it busts xpfe pretty badly... you should be

It doesn't work for me (suiterunner mac).

Comment 22

[Stefan [:stefanh]]

 > It doesn't work for me (suiterunner mac).

What makes me confused is that atm I can't really see any obvious reason for why it *shouldn't* work.

Comment 23

[Robert Kaiser]

Attachment: patch v3.1: use -moz-border-XXX-colors

OK, this one works on both suiterunner and xpfe. I've now used -moz-border-XXX-colors, but without using multiple colors, just with a single one, so that the whole border is using that color, no matter how wide it is. This makes us use a 2px drop indicator on xpfe. This is slightly less beautiful on xpfe but it works well on both versions.

Comment 24

[[e-mail]]

Comment on attachment 260839 [details] [diff] [review]
patch v3.1: use -moz-border-XXX-colors

You could probably get a (slightly different) 1px drag effect in xpfe by using ThreeDDarkShadow transparent; colours. r+sr=me either way.

Comment 25

[Robert Kaiser]

I like it better with the single color, even on xpfe - due to this a bit hackish border-based drag feedback, that line is already jumping when focus goes to a neighboring element - when using two colors, it would visually jump a greater distance, which is even worse IMO.

Checked in and fixed.

Stefan, does this variant work on Mac as well? If not, could you investigate this?

Comment 26

[Stefan [:stefanh]]

> Stefan, does this variant work on Mac as well? If not, could you investigate
> this?

I just checked a phlox build and it does seem to work on mac :)

Comment 27

[[e-mail]]

(In reply to comment #25)
>I like it better with the single color, even on xpfe - due to this a bit
>hackish border-based drag feedback, that line is already jumping when focus
>goes to a neighboring element - when using two colors, it would visually jump a
>greater distance, which is even worse IMO.
IMHO that's because the colours were the wrong way around :-(