Closed Bug 195361 Opened 22 years ago Closed 5 years ago

Can't select text from disabled form fields

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 253870
Project Flags:
Webcompat Priority ?
Tracking Flags:
Tracking Status
firefox31 - affected
firefox-esr31 - affected

People

(Reporter: oliver, Unassigned)

References

Details

(Keywords: parity-chrome, parity-ie, parity-opera)

Attachments

(2 files)

testcase #1, Try it in Composer
1.12 KB, text/html
Details
Sketch of a fix
1.67 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 If you setup an input field to be disabled, then composer can not select that input field. Not by: - Ctrl+A - Mouse click - Mouse double click - Mouse drag (selecting others elements) Reproducible: Always Steps to Reproduce: 1. Create an input field with <... disabled="disabled" ...> 2. Try to select the input for deleting of editing 3. you can't Actual Results: You can not delete or edit the input field Expected Results: You should be able to select the input field and the input field should be painted blue Please try the testcase, more instructions and examples are inside the testcase #1
Many instructions and debug info is in the attach, please use it.
*Maybe* related to bug #82547 Please not mark this as dupe of bug #82547, this is not a textarea related issue and is really a especific issue. I searched for "input disabled" and could not find a dupe. Also, the testcase is really explanatory and well documented. Thanks.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming in Mozilla 1.3 on WinXP SP1
-->selection
Assignee: composer → mjudge
Component: Editor: Composer → Selection
Keywords: topembed
OS: Windows XP → All
QA Contact: petersen → pmac
Hardware: PC → All
In my testing I can select the field by text selection drag or with the keyboard and then cut or delete it, but it does not visually appear selected. The click/double-click bug has already been filed (several times). I think that the root cause is that the disabled attribute is overriding any behaviour that we want the field to have :-(
topembed- as I don't think embeddors will run into this very often. If I'm wrong, thwack me
Keywords: topembed → topembed-
Assignee: mjudge → nobody
QA Contact: pmac → selection
Did this bug get lost in the pile? Verified still issue in FF4b8. Was reported again here: https://bugzilla.mozilla.org/show_bug.cgi?id=253870
Still unable to select text in a disabled element. Readonly still submits the form element, there are cases where one wouldn't want to submit it, but want to display it in a disabled box. There are no negative effects of allowing the text to be selectable, but there are cases where it could be useful. Since the data in the field is shown, it should be selectable. It is in IE and Chrome. Right click should also have a copy option. This seems to be related to: https://bugzilla.mozilla.org/show_bug.cgi?id=141432
I'm using Firefox 11.0 under Ubuntu Oneiric and I still can't select the text from a disabled input/textarea. Also, the right button click doesn't open any menu to try get the content with Firebug/Element Inspector.
I can confirm this issue on Firefox 16.01 and 17.0. I cannot select the text. The mouse cursor changes to a text manipulation/selection caret, but when I try to select I don't get any visual feedback indicating something is being selected. If I ignore the lack of visual feedback and hit Ctrl+C anyway and then try to paste to notepad, I see that nothing was copied, I still get the old contents of my clipboard. Note that this did work on Firefox at some point. I think it was one day fixed for Firefox 2 or something and the issue has been re-introduced around the time of Firefox 4. The HTML spec. isn't entirely clear of the intended behavior it seems. It explicitly states that the contents of a disabled input should be immutable and that it should not be sent to the server on form submit, but it says nothing about whether the user should be allowed to select it. There is something to say for not allowing it, but I personally feel that it just makes life inconvenient for the user and does not offer any advantages, so I would say fix it and make it selectable and copyable. Opera (at least at one point) also had issues with this: http://my.opera.com/community/forums/topic.dml?id=281969 And so did Chromium: http://code.google.com/p/chromium/issues/detail?id=152552 Can someone move this issue from NEW to CONFIRMED? It's easy to verify that it indeed exists.
"NEW" means confirmed.
In case it isn't clear, disabling select disable copy & paste. Why in the world would you EVER render text yet disable copy & paste?!?!?! Duplicate bug 253870 was closed as INVALID, with readonly="readonly" suggested as a workaround, I HATE that option. I don't like using readonly="readonly", EVER. It leaves the field focusable and reachable via tab keypress and, if, god forbid, the user hits the backspace key while the read-only field is focused, then most browsers treat it like the user hit the 'back' button and bring up the previously viewed page. Not what you want to see happen when you're filling out a large form, especially if you are using some archaic browser that doesn't preserve the form data when you hit the 'next' button to return to it. Also very, very bad when using some single-page web application, where 'back' takes you to a whole other world, and 'next' doesn't even restore your form, much less its data. Wow, this bug is over 11 years old now. Please, please, Please, PLEASE, just FIX it. This almost has to be something that one of the UI devs should be able to make quick work of. I'm seriously writing code in my web app to dynamically swap out disabled inputs for DIVs and disabled textareas for PRE elements, just to support FF. I really shouldn't have to do that.
Google lead me here. I'm an advocate for getting this fixed as well please. Currently running Firefox 29.0.1 on OSX 10.9.3 Willing to test in Windows 8.1 or 7. Meh Linux as well if you need me to.
I confirm that this is very nasty bug. Also currently in Firefox (ver 30) this bug is the cause of "unique behavior" in comparison with other browsers (IE ver 9! and newer, Google Chrome ver 35 and modern Opera). All mentioned browsers allow to select & copy the value in disabled input element.
blocking-fx: --- → ?
status-firefox31: --- → ?
status-firefox-esr31: --- → ?
tracking-firefox31: --- → ?
tracking-firefox-esr31: --- → ?
(In reply to Oliver) > If you setup an input field to be disabled, then composer can not select that > input field. Not by: > - Ctrl+A > - Mouse click > - Mouse double click As of bug 827017, Composer now edits a disabled text field on double-click. (In reply to Wladimir Uzev from comment #15) > All mentioned browsers allow to select & copy the value in disabled input > element. Interesting, I hadn't noticed that before. (I tried IE 11 and it gives a no-entry cursor but allows you to select the text anyway.)
I do not agree that it is a nasty bug and we won't block the 31 release because of this bug.
blocking-fx: ? → ---
status-firefox31: ? → affected
status-firefox-esr31: ? → affected
tracking-firefox31: ? → -
tracking-firefox-esr31: ? → -
Keywords: topembed-
Summary: If an input field is marked as disabled in a <form>, Composer can't select it → Can't select text from disabled form fields
Whiteboard: [parity IE/Chrome/Opera]
Although the text can be copied from inspector it still is a very non "GUI" situation. Since text is drawn by the browser user must be able to select and copy it. Firefox 38.0 still has the problem.
Ehsan do you know if this is an easy fix?
Flags: needinfo?(ehsan)
Attached patch Sketch of a fix — — Splinter Review
(In reply to David Bolter [:davidb] from comment #27) > Ehsan do you know if this is an easy fix? Yeah it should be pretty simple. Here is a preliminary sketch that fixes selection in disabled input elements. This is missing a few bits: 1. The change in HTMLInputElement::IsHTMLFocusable is wrong. We shouldn't make these elements focusable. The reason I had to include it in this patch is because something is calling this function and canceling a mouse-down/click event which prevents using the mouse to make a selection. If someone wants to fix this, they should set a breakpoint in IsHTMLFocusable to see what code is calling it, and then figure out a way to allow selection without making the element focusable. 2. The fix for #1 should be applied to textareas as well. 3. Since this will affect the behavior of <xul:textbox> as well, we need to investigate whether we should override this behavior for XUL textboxes in order to maintain parity with the native text controls on various platforms. 4. Fix the tests and other things that may depend on the current behavior.
Flags: needinfo?(ehsan)
FYI, Calixte Denizet started to work on it a few days ago. He has a similar patch.
According to W3's recommendation: > The difference between disabled and readonly is that read-only controls are still focusable, > so the user can still select the text and interact with it, whereas disabled controls are > entirely non-interactive. https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#the-readonly-attribute Unless I'm misunderstanding the spec, this seems to be defined behavior rather than a bug.
I think this is irrelevant - for me, I am not talking about 'user interaction' in the sense that a user must or can do something on or with a form. It's about the page: I can copy any text on a page in any browser, except in Firefox the disabled input fields. So I find it a logical problem. Plain text on a page does not have a disabled or readonly attribute, still it's copyable. Images can be copied, too. So why suddenly disable copying for 1 type of object? Illogical.
The spec is not just referring to interaction with the form. It's specifically talking about focusing and selecting text. I think it's important for FF to follow the standards, and if those are bad, then we should work on changing them instead. There are plenty of alternatives, in the mean time. The READONLY attribute for one. If an input field shouldn't be submitted with the form, one could instead put the text inside a DIV, SPAN, or P tag (why would it need to be part of the form if it's not disabled and not going to be submitted?). I realize neither of these solutions are exactly what some are hoping for, but it seems better than breaking from the standards. Incidentally, hopefully the logic is more clear when seen in this light: plain text and images don't have a DISABLED attribute and don't have copying disabled; If a field has a DISABLED attribute then it also has copying disabled.
(In reply to trevorhreed from comment #32) > important for FF to follow the standards, and if those are bad, then we > should work on changing them instead. Can you help changing that standard? > There are plenty of alternatives, in the mean time. The READONLY attribute > for one. Can you help making e.g. the Hungarian State Treasury use any of those alternatives, so I can copy simple amount fields from their fabulous system? For now, for me, the one and only alternative is using another browser.
(In reply to Gergely from comment #33) > Can you help changing that standard? > Can you help making e.g. the Hungarian State Treasury use any of those > alternatives, so I can copy simple amount fields from their fabulous system? Yes. I sent you an email for further discussion.
Whait wat? This issue has been open for 13 years (!) and now we are debating whether it's an actual issue? Ha ha ha this would be soo funny... if it weren't so sad. :( It reminds me of this issue on the Eclipse issue tracker: Bug 108668 - Default text encoding should be set to UTF-8 for all text-based files https://bugs.eclipse.org/bugs/show_bug.cgi?id=108668 Opened 2005-09-02 (actually 2 years older than this issue, but what's years on decades right?) and then on 2014-02-24, an Eclipse contributor says: 'There is really nothing we can do at the Platform/Resources level.' and closes the issue as WONTFIX. Community response? 'Ten years to find out that issue has wrong parameters?!' Totally justified imho. Please guys. I'm a developer that actuallu worked as a support engineer for multiple years so I know a thing or two about issue management... Just count the comments / contributors in the discussion... If there are dozens of people chiming in saying that some bug sucks really hard, that's a pretty good indicator that there really is something there to fix. Saying Firefox is the only browser that does it right, in the face of people reporting the 'right behavior' as a bug and many others chiming in to support that, for over a decade (!!) is just a slap in the face of people taking time out of their day to contribute to this project by reporting issues. What would you feel if the issue you reported would just sit there for years and then finally be dismissed?? Mozilla can and should do better.
The issue doesn't need to be dismissed; it just needs to be moved to a broader community because there is a spec out there and other browsers might decide to implement that spec and cause even more problems, and because developers have already created websites and applications against that spec. Frustration over a 13 year struggle to get something fixed is certainly understandable. If there really is enough momentum for this change in the broader community, then discussing and approving it there will move the change along in Firefox much faster. The challenge with changes like this one is that most of the people that are potentially affected by the change are not even aware a discussion is taking place. They are content with the existing functionality and therefore have no need to search for, find, and join in this discussion. Imagine their frustration if a behavior defined in a community standard (something a very broad community all agreed to), a behavior that has been working a certain way for 13 years were to suddenly start working differently? These kind of problems are exactly why we have (and need) specs.
So Chrome is switching to our behavior (text not being selectable inside disabled form fields) as well [1]. Let's close it as INVALID now. Anyone who thinks text inside disabled form fields should be selectable could submit an issue to the HTML Standard [2] so that we can discuss there. Also the user-select property in CSS Basic User Interface Module Level 4 [3] may be related as well. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=626581 [2] https://github.com/whatwg/html/issues/new [3] https://drafts.csswg.org/css-ui-4/#user-interaction
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
> Anyone who thinks text inside disabled form fields should be selectable could submit an issue to the HTML Standard Do you really not agree that it is weird that everything on a web page, headers, paragraphs, lists, images, tables, checkboxes... literally *everything*, can be selected, *except* for disabled form controls? What use does this feature have in your opinion? Because what I am seeing (and I've been watching this issue for 4 years now) is a spec (which is now 15 years old) that says that it should not be selectable, but which actually has not been followed for 13 of these 15 years by any browser except for Firefox, which is now slowly becoming a reality, mostly because of your hesitation in fixing this bug. If Firefox would have fixed this issue in 2003 when it was reported, the wording of the spec would almost certainly have been changed to match the de facto behavior of all browsers, as did most other things where the spec and reality deviated in HTML5. But alas you did not fix it. There was no consensus amongs browser vendors, so HTML5 could not standardize the (imho correct) behavior. And now we are stuck with it. At users expense. There is not a single person that benefits from this 'feature'. If you think there is, I challenge you to explain a scenario where this feature is beneficial to users. > I think it's important for FF to follow the standards, and if those are bad, then we should work on changing them instead. But that's not happening is it? If those are bad... If? The user cannot select the text (say some product ID) that is in the form field... Why not? Is it secret? Then why show it? Will you stop me from selecting it through the dev tools? Is it a security feature?? A friend witnessed me using the dev tool to accomplish something on a web page (forgot what it was exactly) and said: 'it's so unfair that you can do that! Normal people can't do that!'. I so got what she meant. Why am I allowed to select this text (from source or dev tools) when the normal user is not? What bad will happen if she selects it? What is the purpose? We are blocking her access to this content... Surely we have a good reason? What is it?
+1, Stijn de Witt!!!
(In reply to Stijn de Witt from comment #38) > > Anyone who thinks text inside disabled form fields should be selectable could submit an issue to the HTML Standard > > Do you really not agree that it is weird that everything on a web page, > headers, paragraphs, lists, images, tables, checkboxes... literally > *everything*, can be selected, *except* for disabled form controls? FWIW, it is not the only thing which is not selectable. CSS has a property called user-select [1], and anything with "user-select: none" would not be selectable, no matter it is header, paragraph, or anything else. And this kind of feature is a long-time requirement from web developers so that they can simulate behavior on native apps. It could also be used when selection would break the rendering effect. Making disabled form control not selectable matches what native app does, and should in general be the expected behavior. Developers should use "readonly" rather than "disabled" if they want user be able to select the text inside. > Because what I am seeing (and I've been watching this issue for 4 years now) > is a spec (which is now 15 years old) that says that it should not be > selectable, but which actually has not been followed for 13 of these 15 > years by any browser except for Firefox, which is now slowly becoming a > reality, mostly because of your hesitation in fixing this bug. I do not hesitate in fixing this bug. I oppose to fix this bug. I think what the spec says here makes sense, and consequently I pushed other browsers to follow the same behavior. And that's why I asked you to file issue to the spec if you think it is wrong, and provide your justification there. [1] https://drafts.csswg.org/css-ui-4/#propdef-user-select
TBH, I think this is a dumb nerd-answer, since "readonly" input fields are not handled the same way as "disabled" input fields. And since we are discussing only 'copy/paste' behavior of displayed text, please do not suggest to use "readonly", but keep focused on the topic which is all about how a user uses a webbrowser. Read this: https://www.w3.org/TR/html401/interact/forms.html#h-17.12 There is no mention there that the selection of text is prohibited. I've also read Selection API draft (21 sep 2016) , The Editing Taskforce (24 aug 2016) and a few other docs, but not found any reference to the disability of selecting text of disabled input fields. - - Marc
There seems to be something wrong with the expected behaviour (Windows only?) of disabled fields. - First time tripple clicking on a disabled field gets it contents selected. - Interacting with the mouse like selecting the text (without seeing whats going on) and drag'n'droping this "hidden" selection into another field the "selected" contents is copied.
Let's do something more constructive. Filed bug 1308698 for allowing using -moz-user-select (or the standard user-select in the future) to control the selectability of disabled text fields. When that gets fixed, switching this behavior would be as simple as changing the property in user agent stylesheet. And users who want a different behavior can also change that with their user stylesheet. (But that doesn't seem to be a trivial bug to fix, nor is it at a high priority at the moment. If anyone is interested in fixing that, it would be appreciated.)
@Marco #42: Please don't giveaway the way to circumvent this bug, the workarounds might get "fixed" ;-) More seriously, I just followed Xidorn's and Trevor's request to go one level higher and try to enhance the spec for all browsers, rather than improving only Firefox. The discussion was already happening on https://github.com/whatwg/html/issues/1852 and Xidorn is active there.
Everyone here (including me) has been complaining about this "bug" for years. 12+ years now. Guess what? The latest Chrome (v54) now mimics the same behavior as Firefox. If a form field has the `disabled` attribute on it, you can no longer select the text in it. We've come full circle here :-)
I thought it was me seeing things... but it's real. Anyway, time has come to rewrite some things.
(In reply to Jake Wilson from comment #45) > Everyone here (including me) has been complaining about this "bug" for > years. 12+ years now. > > Guess what? The latest Chrome (v54) now mimics the same behavior as Firefox. > If a form field has the `disabled` attribute on it, you can no longer select > the text in it. > > We've come full circle here :-) Looks like they've already reverted it as well: https://bugs.chromium.org/p/chromium/issues/detail?id=626581
(In reply to zach.buttram from comment #47) > (In reply to Jake Wilson from comment #45) > > Everyone here (including me) has been complaining about this "bug" for > > years. 12+ years now. > > > > Guess what? The latest Chrome (v54) now mimics the same behavior as Firefox. > > If a form field has the `disabled` attribute on it, you can no longer select > > the text in it. > > > > We've come full circle here :-) > > Looks like they've already reverted it as well: > https://bugs.chromium.org/p/chromium/issues/detail?id=626581 Whoops, wrong link, that was the one that caused the change in the first place. Here's the revert: https://bugs.chromium.org/p/chromium/issues/detail?id=656736
I just wanted to reference the current HTML spec here: "The difference between disabled and readonly is that read-only controls can still function, whereas disabled controls generally do not function as controls until they are enabled. This is spelled out in more detail elsewhere in this specification with normative requirements that refer to the disabled concept (for example, the element's activation behavior, whether or not it is a focusable area, or when constructing the form data set). Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this specification." https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute So there's nothing wrong with letting users copy from disabled fields any more.
This bug was incorrectly closed, as the reason for closing mentioned in comment #37 does not apply anymore: Chrome reverted their change after only a few days. Note that the spec has now been changed and explicitly mentions that it does not define whether or not text can be copied (see comment #49). At this point the current behaviour is not justified by the spec, and goes against what other browsers do. Note: All other browsers support the equivalent of "-moz-user-select", so for people relying on unselectable text the behaviour can be easily achieved.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I have to agree with everyone else here. Firefox is the only mainstream browser with this behavior. Chrome has reverted their recent change and, since the spec was recently reworded, has no plans to reintroduce it. Inconsistency is bad for the web. Text selection should be under the domain of CSS via the user-select property anyway.
+1! Please fix this bug!
As all the arguments have been stated in this bug, I am limiting the comments on this bug to persons who have editbugs permissions to limit the +1 If someone wants to propose a patch and don't have editbugs permissions to do so, please contact me or Ehsan (who wrote a poc in comment #28).
Restrict Comments: true
Keywords: parity-chrome, parity-ie, parity-opera
Whiteboard: [parity IE/Chrome/Opera]

The spec contains:

"Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this standard."

So at least the standard isn't violated. However, it seems desirable to have same behavior across browsers and Chrome's behavior is the one expected by the reporter.

As the issue is present at a web-page (https://www.w3schools.com/code/tryit.asp?filename=G5JI2AUOZP2U), I'll add the webcompat flag.

Webcompat Priority: --- → ?

I just fixed this in bug 253870.

Status: REOPENED → RESOLVED
Closed: 8 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: