[suiterunner] Personal Toolbar expands when items are hovered

RESOLVED FIXED

Status

defect
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: stefanh, Assigned: kairo)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

Reporter

Description

13 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

13 years ago
OS: Mac OS X 10.3 → All

Comment 1

13 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

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

Comment 3

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

13 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 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

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

Comment 10

13 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 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

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

13 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

13 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
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 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
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 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
Closed: 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 :)

(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.