Open Bug 550366 Opened 15 years ago Updated 3 years ago

Location bar doesn't lose "focused" attribute/property when Customize Toolbar window opens

Categories

(Toolkit :: Toolbars and Toolbar Customization, defect)

x86
Windows Vista
defect

Tracking

()

People

(Reporter: darktrojan, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

Attached patch patch v1 (obsolete) — Splinter Review
STR: 1. Open the DOM Inspector 2. In Firefox window, ensure location bar has focus 3. Open the customize toolbar window from the view menu or toolbar context menu 4. In DOM Inspector, go to #urlbar and see that it has focused="true" attribute and JS focused property = true I don't know if this patch is the best solution but it fixes the problem.
Attachment #430484 - Flags: review?(dao)
Attached patch patch v1.1 (obsolete) — Splinter Review
I can't even make simple patches without stupid mistakes. :|
Assignee: nobody → geoff
Attachment #430484 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #430485 - Flags: review?
Attachment #430484 - Flags: review?(dao)
Attachment #430485 - Flags: review? → review?(dao)
I suppose this affects the search bar as well? Would be nice to fix this in a generic way...
Doesn't appear to.
I suppose the search bar isn't affected because its textbox is anonymous content which gets reconstructed from scratch when customizing toolbars. Still, a more general solution seems preferable. How about removing the attribute in the xbl descructor and adding it back in the constructor in case document.activeElement == this.inputField?
That test is never true when the constructor is called due to the urlbar being moved around the DOM. We could call |if (this.focused) this.focus();| in the constructor ... ?
The node doesn't need to move around for the constructor to run. You could set type="autocomplete", for instance. However, I guess the input field could still not be focused anymore, as the anonymous content would be reconstructed. "if (this.focused) ..." in the constructor doesn't seem right, as the attribute shouldn't be there anymore in the first place.
I can't remove the attribute in the destructor because it doesn't get called (bug 230086). Are there any other opportunities to remove it?
customizeToolbar.js could check whether focus is inside of the toolbox and clear it in that case.
(In reply to comment #8) > customizeToolbar.js could check whether focus is inside of the toolbox and > clear it in that case. Geoff, do you want to write such a patch?
Attachment #430485 - Attachment is obsolete: true
Attachment #430485 - Flags: review?(dao)
Assignee: geoff → nobody
Component: Location Bar → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: location.bar → toolbars
Attached patch patch (obsolete) — Splinter Review
This fixes it, but it probably shouldn't be needed. If the input field of a textbox is focused, maybe there should be a blur event before that input field gets destroyed?
Assignee: nobody → dao
Attachment #439191 - Flags: review?(enndeakin)
Attached patch patchSplinter Review
err, that's what I wanted
Attachment #439191 - Attachment is obsolete: true
Attachment #439192 - Flags: review?(enndeakin)
Attachment #439191 - Flags: review?(enndeakin)
Sorry, I've been way too busy to deal with Mozilla stuff lately.
Dão, does the patch in bug 559561 fix this?
(In reply to comment #13) > Dão, does the patch in bug 559561 fix this? No, doesn't seem to.
OK, the patch in bug 559561 is right and the blur does happen, but by the time the event fires the frame for the input has gone away. I'll continue to investigate tomorrow.
No longer blocks: 549835
(In reply to comment #7) > I can't remove the attribute in the destructor because it doesn't get called > (bug 230086). Are there any other opportunities to remove it? Bug 83635, which bug 230086 depends on, is now blocking 1.9.3b1.
(In reply to Neil Deakin from comment #15) > OK, the patch in bug 559561 is right and the blur does happen, but by the > time the event fires the frame for the input has gone away. I'll continue to > investigate tomorrow. Any update on this?
Assignee: dao → nobody
Depends on: 559561
Attachment #439192 - Flags: review?(enndeakin) → review+
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.
No assignee, updating the status.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: