<input> has focus/blur issues when it has focus and its type changes to/from type=number
Categories
(Core :: Layout: Form Controls, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox27 | --- | unaffected |
firefox28 | --- | wontfix |
firefox29 | --- | wontfix |
firefox30 | --- | wontfix |
firefox74 | --- | fixed |
People
(Reporter: jchen, Assigned: emilio)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [webcompat:p1], [wptsync upstream])
Attachments
(4 files, 2 obsolete files)
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Updated•9 years ago
|
Comment 3•9 years ago
|
||
Comment 4•9 years ago
|
||
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 8•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 10•6 years ago
|
||
See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
I could not find a test like this already in the web platform tests (or the Blink or WebKit test suites), so here is a testharness.js WPT (like uievents/click/auxclick_event.html
) which should do the trick.
Assignee | ||
Comment 12•5 years ago
|
||
I had a patch to stop using the hacky anonymous text control for number inputs somewhere in bugzilla, I should probably rescue that patch.
Assignee | ||
Comment 13•5 years ago
|
||
Oh, it was attached to this bug. :-)
I'll try to rebase it.
Assignee | ||
Comment 14•5 years ago
|
||
I have https://treeherder.mozilla.org/#/jobs?repo=try&revision=9b09ae8ee993fb9c9c055118153ef8b32e85b826, which kinda works. I just pushed it to try to see where it stands.
Assignee | ||
Comment 16•5 years ago
|
||
So from the try run:
- Needs some a11y fixes (this should be easy-ish).
- I broke some font inflation stuff looks like, and need to check the placeholder / preview stuff. I probably need to tweak some reflow bits or some CSS there to make layout correct and consistent.
- There's an assert that needs investigation. Potentially related to the above.
- I broke localization of the number but that (a) it is untested (b) it is bogus and (c) no other browser does it.
So all in all seems a bit of work, but probably workable.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 17•5 years ago
|
||
This is also breaking Sunlife's page on Android Firefox browsers, because it causes the on-screen keyboard to never be brought up and users cannot type in their age/etc.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 18•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 19•5 years ago
|
||
Comment on attachment 9115915 [details]
Bug 981248 - Rewrite <input type=number> to avoid an anonymous input. r=masayuki!,jfkthame!,surkov!,jwatt!,ntim!
Mats, Jonathan, interested in your thoughts on this.
I still need to fix a few things, mainly:
- Text has the wrong baseline (though input element uses the right one).
::placeholder
/preview-div
stuff needs to be fixed to be out of flow and positioned with CSS or something, instead of the current thing we do hiding them during the display list...
I still haven't decided whether I want the wrapper div everywhere. It may be worth simplifying the setup, plus it can be the containing block for the placeholder / preview, and thus may save quite a bit of trouble. But I haven't investigated it much.
I also need to look into some of the DOM bits (value sanitization and such), but off-hand the amount of code that goes away looks pretty neat.
Assignee | ||
Comment 20•5 years ago
|
||
Also note, it does change the layout a bit. In particular the buttons now appear inside the <input>
background. But that's a feature IMO, in my experience number inputs at least on Linux look terrible, and with my patch they look nicer to me at least.
Comment 21•5 years ago
|
||
Comment on attachment 9115915 [details]
Bug 981248 - Rewrite <input type=number> to avoid an anonymous input. r=masayuki!,jfkthame!,surkov!,jwatt!,ntim!
Looks great so far! And yes, we might want to merge them eventually, but it's probably better to do that as a follow-up bug.
Updated•5 years ago
|
Assignee | ||
Comment 22•5 years ago
|
||
Masayuki, ni? for https://phabricator.services.mozilla.com/D57193#1760448.
Also, over-all feedback on the patch would be much appreciated, I do like that it removes a bunch of special code in layout and focus management.
Here's a try run with the latest bits of test fixes and such: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cfaca2e461b8471c10cd0ee0ef8a2bbbfceab04
Apart of the input events that I'm asking you about I need to do some work on the a11y bits. But I've discussed that with the a11y folks and it looks straight-forward.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 23•5 years ago
•
|
||
The test fails with my <input type=number> rewrite because editor fails to
dispatch one input event caused by these mouse events.
The reason for this is that we schedule them from an input event, which fires
from here:
Note how at that point we still haven't decremented mPlaceholderBatch. That means
that other stuff that triggers input events from there will not dispatch events.
I think that's a bit unexpected, but it is a preexisting problem, and can't
happen for users because mouse events go through the event loop.
Updated•5 years ago
|
Assignee | ||
Comment 24•5 years ago
|
||
This one should be all green :-)
Assignee | ||
Comment 25•5 years ago
|
||
Comment on attachment 9115915 [details]
Bug 981248 - Rewrite <input type=number> to avoid an anonymous input. r=masayuki!,jfkthame!,surkov!,jwatt!,ntim!
Sent a review request instead, now that's green. Thanks y'all for your help!
Assignee | ||
Comment 26•5 years ago
|
||
Tom, do you want to send the WPT in a separate patch? I verified locally that it passes as expected, but it'd be great if you preserved authorship. I can roll it into the patch above otherwise, but...
A minor nit: It'd be amazing to drop a <link rel="help" href="https://bugzilla.mozilla.org/show_bug.cgi?id=981248">
on the test too, so people looking at the test can get all the context :)
Comment 27•5 years ago
|
||
I'm actually alright with it being part of this patch. If you don't mind dropping that link into it, it should be more than enough of a trail for folks to follow back, if they really are curious who wrote it (or more importantly why). Is that alright with you?
Assignee | ||
Comment 28•5 years ago
|
||
Sure, why not.
Assignee | ||
Updated•5 years ago
|
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 31•5 years ago
|
||
Assignee | ||
Comment 34•5 years ago
|
||
Comment 35•5 years ago
|
||
Comment 37•5 years ago
|
||
Backed out for multiple failures.
backout: https://hg.mozilla.org/integration/autoland/rev/89c1fd1db3b14b99560fa69ff2cb5dd9d2152950
-
https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=gv-junit&revision=1eace7bd28d9986cdd43f5ecb6393a4aa8e9bffc
failure log e.g.: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=284860483&repo=autoland&lineNumber=1440 -
https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=wpt3&revision=1eace7bd28d9986cdd43f5ecb6393a4aa8e9bffc&selectedJob=284862847
failure log e.g.: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=284862847&repo=autoland&lineNumber=48859
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 38•5 years ago
|
||
Comment 40•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Description
•