Middle-click that crosses focus outline does not close tab

RESOLVED DUPLICATE of bug 241622

Status

()

defect
RESOLVED DUPLICATE of bug 241622
13 years ago
9 years ago

People

(Reporter: jruderman, Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
Steps to reproduce:
1. Push the middle mouse button down on the active tab.
2. Mouse the cursor so it crosses the dotted focus outline (but does not leave the tab).
3. Release the middle mouse button.

Result: Tab does not close.

Expected: Tab closes.

This is a recent regression, probably from bug 308396.
Is this still an issue now that bug 317375 has been fixed. Bug 317375 has made outlines transparent to events, so I guess this could be fixed by that.
Sorry, I misunderstood the bug in comment 1.
This regressed between 2006-01-18 and 2006-01-21, so indeed likely a regression from bug 308396.
Posted file testcase
So basically with the fix for bug 308396, I think we now have this situation.
So I guess this is a xbl bug.
However, bug 326851 is related, if bug 326851 is a genuine bug, then a fix for that bug would also fix this bug, I think.
Component: Tabbed Browser → Tabbed Browser
Keywords: testcase
Product: Firefox → Core
QA Contact: tabbed.browser → tabbed-browser
Component: Tabbed Browser → XBL
Assignee: nobody → general
QA Contact: tabbed-browser → ian
So as HTML, I would NOT expect a click here (since the mousedown and mouseup are happening on two different nodes).

Should XBL really behave differently?  If so, then the ESM will need to deal, since that's where we generate our click events from mousedown and mouseup...

But I'm not convinced that XBL should behave differently in this case.  Also, I'd suggest filing a front-end bug on this stuff too, since there's no way I want to be touching the ESM on the 1.8 branch, even if we do decide to make the behavior different in the XBL case.  If the front-end folks care about the problem, they may want to consider a front-end-only change to fix it.
(Reporter)

Comment 6

13 years ago
Why should whether a node sees a click event depend on whether the mouse moved between two of its children during the click?
Boris, I was thinking in the line of bug 53007, except in this case I thought something like: "Need to suppress (retarget) mousedown/mouseup of anonymous content".

Your html testcase is what I filed bug 326851 about. Note that IE6 does fire a click event in this case (and personally, I think it makes sense).
> Why should whether a node sees a click event depend on whether the mouse moved
> between two of its children during the click?

How do you define a "click"?  That's all there is to it.

Retargeting of the DOM mouseup/mousedown events won't help.  They're not used for click event generation.  Again, the magic's in the ESM.
Depends on: 326851
Assignee: xbl → nobody
QA Contact: ian → xbl
(Reporter)

Comment 9

9 years ago
The ESM bug is the same as bug 241622.  We probably don't need a frontend fix now that tabs don't have focus outlines all the time.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 241622
You need to log in before you can comment on or make changes to this bug.