Open Bug 1364197 Opened 5 years ago Updated 5 years ago

A search textbox XUL element is still focused after clicking outside of it


(Core :: XUL, defect, P5)





(Reporter: evanxd, Unassigned)


(Blocks 1 open bug)


(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.

1. Open Preferences page (in general category).
2. Click the "Home Page" textbox (focused) .
3. Click outside of the textbox.

Remove "Home Page" textbox's focus.

"Home Page" textbox still has focus.
As it's an issue of a XUL element, Core::XUL seems a more proper component.
Component: DOM: Events → XUL
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"); });
Hi Mike and Jessica,

What do you think of Comment 2 and this issue?

Flags: needinfo?(mconley)
Flags: needinfo?(jjong)
Whiteboard: [photon-preference]
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)
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:

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)
Flags: qe-verify+
Priority: -- → P2
QA Contact: hani.yacoub
(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)
Flags: needinfo?(chsiang)
Priority: P2 → P3
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)
Blocks: 1357285
No longer blocks: photon-preference
Flags: needinfo?(chsiang)
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.