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)
Tracking
()
NEW
People
(Reporter: darktrojan, Unassigned)
References
Details
Attachments
(1 file, 3 obsolete files)
|
874 bytes,
patch
|
enndeakin
:
review+
|
Details | Diff | 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)
| Reporter | ||
Comment 1•15 years ago
|
||
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)
| Reporter | ||
Updated•15 years ago
|
Attachment #430485 -
Flags: review? → review?(dao)
Comment 2•15 years ago
|
||
I suppose this affects the search bar as well? Would be nice to fix this in a generic way...
| Reporter | ||
Comment 3•15 years ago
|
||
Doesn't appear to.
Comment 4•15 years ago
|
||
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?
| Reporter | ||
Comment 5•15 years ago
|
||
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 ... ?
Comment 6•15 years ago
|
||
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.
| Reporter | ||
Comment 7•15 years ago
|
||
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?
Comment 8•15 years ago
|
||
customizeToolbar.js could check whether focus is inside of the toolbox and clear it in that case.
Comment 9•15 years ago
|
||
(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?
Updated•15 years ago
|
Attachment #430485 -
Attachment is obsolete: true
Attachment #430485 -
Flags: review?(dao)
Updated•15 years ago
|
Assignee: geoff → nobody
Component: Location Bar → Toolbars and Toolbar Customization
Product: Firefox → Toolkit
QA Contact: location.bar → toolbars
Comment 10•15 years ago
|
||
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)
Comment 11•15 years ago
|
||
err, that's what I wanted
Attachment #439191 -
Attachment is obsolete: true
Attachment #439192 -
Flags: review?(enndeakin)
Attachment #439191 -
Flags: review?(enndeakin)
| Reporter | ||
Comment 12•15 years ago
|
||
Sorry, I've been way too busy to deal with Mozilla stuff lately.
Comment 13•15 years ago
|
||
Dão, does the patch in bug 559561 fix this?
Comment 14•15 years ago
|
||
(In reply to comment #13)
> Dão, does the patch in bug 559561 fix this?
No, doesn't seem to.
Comment 15•15 years ago
|
||
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.
Comment 16•15 years ago
|
||
(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.
Comment 17•14 years ago
|
||
(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?
Updated•11 years ago
|
Assignee: dao → nobody
Updated•11 years ago
|
Attachment #439192 -
Flags: review?(enndeakin) → review+
Comment 19•7 years ago
|
||
No assignee, updating the status.
Comment 20•7 years ago
|
||
No assignee, updating the status.
Comment 21•7 years ago
|
||
No assignee, updating the status.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•