Closed Bug 1461706 Opened 2 years ago Closed Last year

"-moz-appearance: textfield" used on load on a disabled input type="number" field allows you to enter into the field

Categories

(Core :: Layout: Form Controls, defect, P3)

60 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- verified
firefox61 --- wontfix
firefox62 --- verified
firefox63 --- verified

People

(Reporter: dannyjkirkham, Assigned: emilio)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180503143129

Steps to reproduce:

Create a disabled input type number field "<input type=''number' disabled>" on a page which contains the style rule "-moz-appearance: textfield" applied to the input field. Then click on the field and start typing.


Actual results:

Typing into the field is allowed and what is written into the field is visible as if the field was not disabled.


Expected results:

Field should not be focusable and should not allowed text to be typed in
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
20180515100038
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Priority: -- → P3
I have experienced the same issue on Windows, however it does not happen 100% of the time as far as my experience goes. Aside from this the number input field does act as disabled as it does not fire any events even though you can indeed focus it and enter values in it.
Duplicate of this bug: 1484913
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=da3f01a609c06d5d8cf0c4f9d3e852b7f5952055&tochange=cb1d0640b36e7147c2b014e8dcff572fb022d507
Blocks: 1405087
Has Regression Range: --- → yes
Component: Layout: Form Controls → DOM: Events
Flags: needinfo?(emilio)
Keywords: regression
Summary: macOS: "-moz-appearance: textfield" used on load on a disabled input type="number" field allows you to enter into the field → "-moz-appearance: textfield" used on load on a disabled input type="number" field allows you to enter into the field
Thanks for the test-case. This is really a pre-existing bug, it only happened to be wallpapered. I noticed the same bug before here:

  https://searchfox.org/mozilla-central/rev/71ef4447db179639be9eff4471f32a95423962d7/layout/forms/nsNumberControlFrame.cpp#430
Assignee: nobody → emilio
Component: DOM: Events → Layout: Form Controls
I noticed this bug while fixing bug 1478069, but it goes back way earlier.
Flags: needinfo?(emilio)
Thanks a lot for the regression range btw!
Comment on attachment 9002711 [details]
Sync disabled state of number control regardless of appearance.

Jonathan Watt [:jwatt] has approved the revision.
Attachment #9002711 - Flags: review+
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3de16fbc247b
Sync disabled state of number control regardless of appearance. r=jwatt
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/12615 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
https://hg.mozilla.org/mozilla-central/rev/3de16fbc247b
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Is the user impact here high enough to justify backport consideration?
Flags: qe-verify+
Flags: needinfo?(emilio)
Flags: in-testsuite+
Comment on attachment 9002711 [details]
Sync disabled state of number control regardless of appearance.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> Is the user impact here high enough to justify backport consideration?

Given the fix is a one-liner that I had identified long before, I'd say so.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: Trivial correctness fix.
User impact if declined: see comment 0 
Fix Landed on Version: 63
Risk to taking this patch (and alternatives if risky): not risky.
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/Bug causing the regression]: Technically bug 1405087, but the bug was present before already.
[User impact if declined]: see comment 0.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Not yet, but should be trivial.
[Needs manual test from QE? If yes, steps to reproduce]: I think not, but if you disagree see comment 0.
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not risky
[Why is the change risky/not risky?]: one-liner that avoids forgetting a function call in a shortcut path.
[String changes made/needed]: none
Flags: needinfo?(emilio)
Attachment #9002711 - Flags: approval-mozilla-esr60?
Attachment #9002711 - Flags: approval-mozilla-beta?
Comment on attachment 9002711 [details]
Sync disabled state of number control regardless of appearance.

Simple fix with a test for disabled input fields accepting input when they shouldn't be. Approved for 62.0b20 and ESR 60.2.
Attachment #9002711 - Flags: approval-mozilla-esr60?
Attachment #9002711 - Flags: approval-mozilla-esr60+
Attachment #9002711 - Flags: approval-mozilla-beta?
Attachment #9002711 - Flags: approval-mozilla-beta+
I’ve verified this issue using the testcase from comment 1, on latest Nightly 63.0a1 (2018-08-22) and Beta 62.0b20 (20180823024525).

One difference I noticed between OSes, was that on macOS 10.12 the mouse cursor disappear after clicking on the field, as you start typing.

Not sure if this is the expected behavior, can you please clarify this, Emilio?
Flags: needinfo?(emilio)
I'm not sure either as I don't own a mac, but as long as it's the same behaviour that we have for <input type="text"> it should be fine.
Flags: needinfo?(emilio)
Thanks Emilio! It seems that the same behavior can be seen for <input type="text"> as well, on OS X.

This is also verified on 60.2.0esr (20180824183244) running Win 10 x64, macOS 10.13 and Ubuntu 16.04 x64. 

Marking the bug as verified fixed per this comment and comment 18.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.