Closed Bug 978048 Opened 6 years ago Closed 6 years ago

Customization mode outlines don't appear when moving the mouse over an empty space

Categories

(Firefox :: Toolbars and Customization, defect)

30 Branch
x86
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox29 --- verified
firefox30 --- verified

People

(Reporter: phlsa, Assigned: Gijs)

References

Details

(Whiteboard: [Australis:P3-])

Attachments

(1 file, 2 obsolete files)

I'm seeing this issue on Windows 8.1 and Windows XP:

When moving the mouse over an empty part of the tab strip, I don't see an outline.
When moving the mouse over an icon in the tab strip (or the tabs themselves), the outline is there.
When dragging an icon to the tab strip, the outline is visible, regardless of the distinction above.
Over in bug 978091, Tim said he can't reproduce this on a clean profile. Can you? :-)
Flags: needinfo?(philipp)
(In reply to :Gijs Kruitbosch from comment #1)
> Over in bug 978091, Tim said he can't reproduce this on a clean profile. Can
> you? :-)

Yes, it also happens in a brand new profile on both Windows 8.1 and XP
Flags: needinfo?(philipp)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
So the window dragging utils is canceling mozmousehittest and I suspect that that's causing this kind of stuff to happen. Which is interesting. In any case, I'm just adding/removing this attribute thing and then maybe this will work. Right? Testing this on Windows in a bit.
Attached patch Patch (obsolete) — Splinter Review
That didn't work, but this does, surprisingly. :-)
Attachment #8387791 - Attachment is obsolete: true
Attachment #8387838 - Flags: review?(jaws)
Comment on attachment 8387838 [details] [diff] [review]
Patch

Review of attachment 8387838 [details] [diff] [review]:
-----------------------------------------------------------------

Felipe, can you review this? I think you're more familiar with MozMouseHitTest than I am.
Attachment #8387838 - Flags: review?(jaws) → review?(felipc)
This is sad, but I think this is the best fix considering timeline.
Attachment #8387838 - Attachment is obsolete: true
Attachment #8387838 - Flags: review?(felipc)
Attachment #8387892 - Flags: review?(jaws)
On IRC we talked about this, the gist is that due to how the Aero API from Windows works, to activate Aero dragging in the titlebar parts of the UI we need to forfeit receiving normal mouse events on those areas.
Some possible solutions, which none are perfect, are:

 - opt out of Aero dragging inside the outline in customize mode, and no dragging would occur
 - opt out of Aero dragging inside the outline in customize mode, and implement manual JS dragging (by tracking mousedown/mousemoves and calling window.moveTo)
 - Hack around by applying the outline styling using JS instead of :hover. I tried something like that, and it works kinda well, but there's no way to make it reliable on the edge of the window (i.e. when the mouse quickly moves from the toolbar to outside of the window)
 - Come up with some workaround in widget code, which I think could be doable but not upliftable for beta

With all these sucky options, Gijs opted for removing the outline for now. FWIW, if [1] would be acceptable it would be an easy fix.
(In reply to :Felipe Gomes from comment #7)
>  - opt out of Aero dragging inside the outline in customize mode, and no
> dragging would occur
>  - opt out of Aero dragging inside the outline in customize mode, and
> implement manual JS dragging (by tracking mousedown/mousemoves and calling
> window.moveTo)

> With all these sucky options, Gijs opted for removing the outline for now.
> FWIW, if [1] would be acceptable it would be an easy fix.

Don't know which of these you meant, but the problem is also that there are still more bugs specifically with these elements, in particular bug 979630. So I think that outright removing them is a lot simpler than trying to hack around the multitude of issues. :-(
Comment on attachment 8387892 [details] [diff] [review]
Remove drag area highlighting

Philipp, are you ok with removing the outline?
Attachment #8387892 - Flags: ui-review?(philipp)
Comment on attachment 8387892 [details] [diff] [review]
Remove drag area highlighting

Looks good!
Attachment #8387892 - Flags: ui-review?(philipp) → ui-review+
Attachment #8387892 - Flags: review?(jaws) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/997a18bcc2d6
Whiteboard: [Australis:P3-] → [Australis:P3-][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/997a18bcc2d6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3-][fixed-in-fx-team] → [Australis:P3-]
Target Milestone: --- → Firefox 30
Comment on attachment 8387892 [details] [diff] [review]
Remove drag area highlighting

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis / bug 963576
User impact if declined: weird behaviour of tabstrip/menubar outline
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): none
String or IDL/UUID changes made by this patch: none
Attachment #8387892 - Flags: approval-mozilla-aurora?
Attachment #8387892 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8387892 [details] [diff] [review]
Remove drag area highlighting

As a said in-person, we should have added new rules to hide the pseudo elements "content: none;" in the cases where this is a problem. This would have also avoided making the selectors more complex. We could have left the outlines as they were on OS X AFAICT.
Attachment #8387892 - Flags: feedback-
Keywords: verifyme
Unfortunately, qa can't reproduce this issue on builds with this bug (and no fix), so we can't really verify it reliably either.

Philipp, can you please check if this is fixed for you in Firefox 29?
Flags: needinfo?(philipp)
Keywords: verifyme
(In reply to Ioana Budnar, QA [:ioana] from comment #16)
> Unfortunately, qa can't reproduce this issue on builds with this bug (and no
> fix), so we can't really verify it reliably either.
> 
> Philipp, can you please check if this is fixed for you in Firefox 29?

Yes, 29 uses the intended behavior.
Flags: needinfo?(philipp)
Status: RESOLVED → VERIFIED
Blocks: 1344178
You need to log in before you can comment on or make changes to this bug.