DESCRIPTION: Right-clicking on a link puts it permanently into a state that matches ":hover" in CSS. STEPS TO REPRODUCE: * Load http://www.fas.harvard.edu/~dbaron/ * Right click on a link ACTUAL RESULTS: The link's background changes to maroon, and it stays that way. EXPECTED RESULTS: The link's background should only be maroon while the mouse pointer is over the link. DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-10-03-08-M11
Assignee: don → trudelle
Component: Browser-General → XP Toolkit/Widgets
Changing component to "XP Toolkit/Widgets" since this has to do with context menus and I think that's the right place...
reassigning to saari as p3 for m15
[Contextual menu bug --- QA Assigning to self.]
Summary: right-clicking on link puts it into :hover state forever → right-clicking on link puts it into :focus state forever
It's actually the :focus state, not the :hover state (the :focus and :hover colors on the given page are the same - I quickly changed one of them to test).
Component: XP Toolkit/Widgets → XPMenus
QA Contact: elig → sairuh
reassign QA contact to me & updated component.
I think this is either fixed or it's a duplicate of bug 21363.
But right clicking on a link does put it into :focus. Should it?
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
Pink, I think this is actually the bug with mouse events going to the parent window instead of the popup.
Assignee: saari → pinkerton
Target Milestone: M15
no, it has nothing to do with parent/child as far as i can tell. it's also XP, though the mac seems to make the link active as well while the other platforms don't.
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Target Milestone: M16
moving all defects not directly related to P0 beta2 features off to M18.
Target Milestone: M16 → M18
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
futuring. it's easy to get out of this state, and mostly harmless.
Target Milestone: M21 → Future
i suspect this is because we eat the event that dismisses the popup and don't let it through to gecko. As a result, the click to take it out of the focus state never gets through. Is this that bad? *shrug*
As noted in the 7-25 comment above, this bug is less serious than it was when it was originally filed.
I think this should be wontfix, because removing focus from the link (and putting it where?) would make it impossible to focus a link using the mouse. In IE, I can right-click a link and then click on the title bar to give the link focus. What's the bug number for eating clicks that dismiss context menus?
Hmm, maybe I misinterpreted the bug. I'm still confused about what the current problem is.
Ok, I guess the question is whether a left-click that cancels a context menu should move focus. I say it shouldn't, because it would be confusing to move focus without also activating the element clicked on. See bug 21390 for a discussion of whether a click cancelling a menu should "go through".
Agreed. The originally reported bug is fixed, and maybe there's nothing else to do here.
Ok, wfm then.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.