Open
Bug 1364197
Opened 8 years ago
Updated 2 years ago
A search textbox XUL element is still focused after clicking outside of it
Categories
(Core :: XUL, defect, P5)
Core
XUL
Tracking
()
NEW
People
(Reporter: evanxd, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [photon-preference])
Gecko doesn't blur a textbox XUL element after clicking outside of it (background). The root cause is that the gecko doesn't file a `blur` event after doing the click.
STR:
1. Open Preferences page (in general category).
2. Click the "Home Page" textbox (focused) .
3. Click outside of the textbox.
Expected:
Remove "Home Page" textbox's focus.
Actual:
"Home Page" textbox still has focus.
Comment 1•8 years ago
|
||
As it's an issue of a XUL element, Core::XUL seems a more proper component.
Component: DOM: Events → XUL
Reporter | ||
Comment 2•8 years ago
|
||
After investigating, I found out that the HTML input (<html:input>) belonged to the textbox element (Home Page textbox) doesn't receive a `blur` event when clicking the outside of the textbox.
We could reproduce the above issue with inputting the below script into the Firefox debugger.
```
var browserHomePage = document.querySelector("#browserHomePage");
var browserHomePageHtmlInput = document.getAnonymousNodes(browserHomePage)[0].querySelector("input");
browserHomePageHtmlInput.addEventListener("blur", function() { console.log("blur"); });
```
Reporter | ||
Comment 3•8 years ago
|
||
Hi Mike and Jessica,
What do you think of Comment 2 and this issue?
Thanks.
Flags: needinfo?(mconley)
Flags: needinfo?(jjong)
Reporter | ||
Updated•8 years ago
|
Whiteboard: [photon-preference]
Comment 4•8 years ago
|
||
Does this bug break the spec? If not, I suspect we've been shipping this bug for a while, and we can probably keep shipping it until we either:
a) Decide that the problem is bad enough to fix it
b) Decide to re-implement about:preferences as HTML
Flags: needinfo?(mconley)
Comment 5•8 years ago
|
||
The browserHomePage textbox blur event is not fired because it can't find a next element to focus or because it thinks the element to be focused is the same element. If you click on another "focusable" element, e.g. another textbox, it acts correctly.
It seems that this is the default behavior in xul (which I'm not sure if it's right), the same thing happens on the example on mdn: https://developer.mozilla.org/samples/xultu/examples/ex_boxes_2.xul
And note that, on this example, if you move away your focus (e.g., click on the url bar) then click on the background of the page again, the focus is redirected to the last focused element. Although this is not the case in Preferences page.
Yeah, I agree with Mike on a) and b). :)
Flags: needinfo?(jjong)
Updated•8 years ago
|
Flags: qe-verify+
Priority: -- → P2
QA Contact: hani.yacoub
Reporter | ||
Comment 6•8 years ago
|
||
(In reply to Mike Conley (:mconley) from comment #4)
> Does this bug break the spec? If not, I suspect we've been shipping this bug
> for a while, and we can probably keep shipping it until we either:
Yes, this break spec. But after discussed with Tina and Cindy in person, they also think we could re-prioritize this issue as P3 bug.
Flags: needinfo?(thsieh)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(chsiang)
Reporter | ||
Updated•8 years ago
|
Priority: P2 → P3
Reporter | ||
Updated•8 years ago
|
Blocks: photon-preference
Comment 7•8 years ago
|
||
Hello folks, thanks for investing time on it.
Though it breaks the spec, I'm fine with pushing it back to p3 since it's not just a case for preferences. We can implement it in design system project.
Flags: needinfo?(thsieh)
Reporter | ||
Updated•8 years ago
|
Updated•7 years ago
|
Priority: P3 → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•