Closed Bug 561243 Opened 14 years ago Closed 14 years ago

Name field in edit bookmarks panel ignores mouse events while focused

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- final+

People

(Reporter: tchung, Assigned: enndeakin)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100421 Minefield/3.7a5pre

within the bookmark star pane menu, i am unable to drag and highlight the text in the Name field and make edits.   The only way to move the cursor with the mouse is to click away and click back in the space you want.

This problem doesnt happen with the tags textfield, to compare.

Repro:
1) download the 4/21 mac trunk nightly
2) visit any website
3) click the bookmark star pane to open the popup
4) Verify clicking and dragging using the mouse to highlight the Name, or edit text, does not work.  Only after clicking away in another textfield and back can you at least move the cursor space.

Expected:
- click, drag, highlight the mouse cursor in the Name field of star pane

Actual:
- click cursor once, then no way to edit anymore with the mouse and highlight
blocking2.0: --- → ?
Summary: cannot highlight Name field using mouse cursor → Name field in edit bookmarks panel ignores mouse events while focused
Tony, is still still reproduceable on current nightly?
Yes, it is.

When I click on it using the DOM Inspector's "Find node by clicking" button I land on the menulist instead of on the html:input inside it.

The bug goes away when I remove the outline style set on the .menulist-editable-box here:
http://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser/browser.css#1323
(by setting style="outline-style: none" on the .menulist-editable-box using DOM Inspector).

Sounds like a layout issue to me.

Tony or Henrik, could you look for a regression window?
Looks like 575242 and 580635 are duplicates of this bug.  I'm experiencing it in the release version 3.6.7.
blocking2.0: ? → final+
Assignee: nobody → margaret.leibovic
I think this affects all editable menulists. The most useful thing to do here is probably to create a minimal testcase and to find the regression range.
After looking into this, I agree with comment 2. Is there a layout person we can put on this?

Also, I couldn't replicate the bug on Windows 7, so it seems like a Mac-specific issue, but I haven't tried other platforms.
Assignee: margaret.leibovic → nobody
Component: Bookmarks & History → Layout
Product: Firefox → Core
QA Contact: bookmarks → layout
Keywords: testcase-wanted
testcase-wanted was added to this bug.  Could someone explain why?  The steps to reproduce in Comment 1 were quite clear.
(In reply to comment #8)
> testcase-wanted was added to this bug.  Could someone explain why?  The steps
> to reproduce in Comment 1 were quite clear.

If it's a layout bug, a reduced test case would likely be handy.
I've done a regression search and come to the conclusion that this was caused by bug 489127.

In this range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6bdb8153b671&tochange=657bebceeb18
the name field stopped responding to mouse events in all states, even when not focused. Bug 558162 was filed about this issue and then subsequently fixed by bug 557987. However, the focused state wasn't fixed by that patch.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/04/2010-04-11-03-mozilla-central/firefox-3.7a5pre.en-US.mac.dmg
is the first build that includes the fix for bug 557987 and it shows the broken-when-focused behavior.
Attached file testcase
This bug is caused by the outline on the editable area.

Bug 597557 'fixes' this by removing the outline, but it does not fix the underlying issue.
Keywords: testcase-wanted
Attached patch Patch (obsolete) — Splinter Review
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
The old code before the original bug 489127 that caused this returned null right away if mList.HitTest returned null, but the current code adds mTargetFrame to the returned list of frames. This patch removes this to give the original behaviour.

This seems to prevent the outline from being considered in the display list.
Attachment #492740 - Attachment is obsolete: true
Attachment #493021 - Flags: review?(roc)
Whiteboard: [has patch][needs review roc]
Keywords: checkin-needed
Whiteboard: [has patch][needs review roc] → [has patch][can land]
http://hg.mozilla.org/mozilla-central/rev/a497aacc2fa0
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][can land]
Flags: in-testsuite+
Target Milestone: --- → mozilla2.0b8
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101204 Firefox/4.0b8pre ID:20101204030328
Status: RESOLVED → VERIFIED
Flags: in-litmus-
Will this fix find its way into the 3.6.x releases?  It's a pretty severe usability bug.  I was disappointed to see it wasn't in 3.6.13 today.
Could someone please clarify exactly how to resolve this bug on a Macintosh Intel Mac with OS 10.6?
Could someone please clarify exactly how to resolve this bug on a Macintosh Intel Mac with OS 10.6?
The fix for this bug is only in Firefox 4. You can download a beta or nightly build if you want test it.
You need to log in before you can comment on or make changes to this bug.