[suiterunner] Personal Toolbar expands when items are hovered

RESOLVED FIXED

Status

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: stefanh, Assigned: kairo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

12 years ago
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.
(Reporter)

Updated

12 years ago
OS: Mac OS X 10.3 → All

Comment 1

12 years ago
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.
(Reporter)

Comment 2

12 years ago
You can actually overrule this behaviour by manipulating padding/margin etc of .bookmark-item:hover.
(Assignee)

Comment 3

12 years ago
Created attachment 254162 [details] [diff] [review]
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).
Assignee: general → kairo
Status: NEW → ASSIGNED
Attachment #254162 - Flags: superreview?(neil)
Attachment #254162 - Flags: review?(neil)

Comment 4

12 years ago
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

12 years ago
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

12 years ago
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...
(Assignee)

Comment 7

12 years ago
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

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

Because bug 361159 fixes this.
Attachment #254162 - Flags: superreview?(neil)
Attachment #254162 - Flags: review?(neil)
(Assignee)

Comment 9

12 years ago
If my new patch on bug 361159 is taken, we need this simple fix again.
(Assignee)

Comment 10

12 years ago
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)
Attachment #254162 - Flags: superreview?(neil)
Attachment #254162 - Flags: review?(neil)

Comment 11

12 years ago
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.
Attachment #254162 - Flags: superreview?(neil)
Attachment #254162 - Flags: review?(neil)
Attachment #254162 - Flags: review-
(Assignee)

Comment 12

12 years ago
Created attachment 255792 [details] [diff] [review]
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.
Attachment #254162 - Attachment is obsolete: true
Attachment #255792 - Flags: superreview?(neil)
Attachment #255792 - Flags: review?(neil)

Comment 13

12 years ago
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

12 years ago
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.
Attachment #255792 - Flags: superreview?(neil)
Attachment #255792 - Flags: review?(neil)
Attachment #255792 - Flags: review-

Comment 15

12 years ago
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.
(Reporter)

Comment 16

12 years ago
(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.
(Reporter)

Comment 17

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

I was wrong, I see it on my trunk debug build
(Assignee)

Comment 18

12 years ago
Created attachment 260128 [details] [diff] [review]
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.
Attachment #255792 - Attachment is obsolete: true
Attachment #260128 - Flags: superreview?(neil)
Attachment #260128 - Flags: review?(neil)
(Reporter)

Comment 19

12 years ago
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

12 years ago
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?)
Attachment #260128 - Flags: superreview?(neil)
Attachment #260128 - Flags: superreview-
Attachment #260128 - Flags: review?(neil)
Attachment #260128 - Flags: review+
(Reporter)

Comment 21

12 years ago
(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).
(Reporter)

Comment 22

12 years ago
 > 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.
(Assignee)

Comment 23

12 years ago
Created attachment 260839 [details] [diff] [review]
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.
Attachment #260128 - Attachment is obsolete: true
Attachment #260839 - Flags: superreview?(neil)
Attachment #260839 - Flags: review?(neil)

Comment 24

12 years ago
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.
Attachment #260839 - Flags: superreview?(neil)
Attachment #260839 - Flags: superreview+
Attachment #260839 - Flags: review?(neil)
Attachment #260839 - Flags: review+
(Assignee)

Comment 25

12 years ago
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?
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Reporter)

Comment 26

12 years ago
> 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

12 years ago
(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 :-(
You need to log in before you can comment on or make changes to this bug.