460682 - Moving a unified window by clicking between two bookmark toolbar items causes them to flicker

Status: NEW

(Toolkit :: Toolbars and Toolbar Customization, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081019 Minefield/3.1b2pre ID:20081019020302

With the fix on bug 398928 we are able to move a unified window by simply dragging one of its toolbars. Means that you can also do this action by clicking the empty area of the bookmarks toolbar and drag it around. But doing this between two items on this toolbar causes these items to get the active state for short intervals. 

Steps:
1. Create new folders or bookmarks on the bookmarks toolbar until you have at least to items
2. Click between two of these items
3. Drag the window around

As you can see depending on the direction of movement the items get pushed for a short interval when moving the window around. That should not happen. They should stay normal.

Comment 1

[Markus Stange [:mstange]]

(In reply to comment #0)
> But doing
> this between two items on this toolbar causes these items to get the active
> state for short intervals. 

You're talking about the :hover state.

I think there are two ways to fix this:
  Option 1: Make window moving cause a mouse move event to be fired.
            This mouse move event would carry the new mouse location in the
            window and thus cause the :hover state to be unset. However, there
            could still be flickering.
  Option 2: Introduce some workaround in the CSS that doesn't set the hover
            style when the mouse is down. I'm thinking about something like
              - toolbarbutton.bookmark-item:hover {
              + window:not(:active) toolbarbutton.bookmark-item:hover {

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sorry, yes I meant the hovering.

When I compare the dragging to Safari you will see that our window is a bit lazy. While you are moving the mouse the window needs a short while until it jumps to the new position. That's why the cursor hovers the nearest bookmark items and causes the hover style to be active. Isn't it a core issue to make the window faster in following mouse movements?

Comment 3

[Markus Stange [:mstange]]

(In reply to comment #2)
> When I compare the dragging to Safari you will see that our window is a bit
> lazy.

I can't see a difference on my machine.

> While you are moving the mouse the window needs a short while until it
> jumps to the new position. That's why the cursor hovers the nearest bookmark
> items and causes the hover style to be active.

That's not really the cause. The problem is that the :hover state is set with the by the same mouse event that we use for moving the window - an event with old coordinates.

> Isn't it a core issue to make
> the window faster in following mouse movements?

It's possible that there's room for optimization. In a quick profiling session I've seen that we spend about 15% of the time updating the screenX and screenY attributes of the <window> element. However, optimizing it wouldn't solve this bug.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #3)
> > When I compare the dragging to Safari you will see that our window is a bit
> > lazy.
> 
> I can't see a difference on my machine.

Probably I had a high cpu load when I tested this. I cannot see it anymore.

> That's not really the cause. The problem is that the :hover state is set with
> the by the same mouse event that we use for moving the window - an event with
> old coordinates.

Than this is correct.