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

Status: VERIFIED FIXED

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

Description

[danny]

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

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
20180515100038

Comment 2

[hi]

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.

Comment 4

[Gingerbread Man]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=da3f01a609c06d5d8cf0c4f9d3e852b7f5952055&tochange=cb1d0640b36e7147c2b014e8dcff572fb022d507

Comment 5

[Emilio Cobos Álvarez (:emilio)]

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

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Sync disabled state of number control regardless of appearance.

I noticed this bug while fixing bug 1478069, but it goes back way earlier.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Thanks a lot for the regression range btw!

Comment 8

[Jonathan Watt [:jwatt]]

Comment on attachment 9002711 [details]
Sync disabled state of number control regardless of appearance.

Jonathan Watt [:jwatt] has approved the revision.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3de16fbc247b
Sync disabled state of number control regardless of appearance. r=jwatt

Comment 10

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/12615 for changes under testing/web-platform/tests

Comment 11

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/3de16fbc247b

Comment 13

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Is the user impact here high enough to justify backport consideration?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

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

Comment 16

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/30415990f75b

Comment 18

[Ciprian Georgiu, Desktop QA]

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?

Comment 19

[Emilio Cobos Álvarez (: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.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/2d1beffe431d

Comment 21

[Ciprian Georgiu, Desktop QA]

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.