743265 - scrollbar covers text in textarea with wrap off

Status: RESOLVED INCOMPLETE

(Web Compatibility :: Site Reports, defect, P5)

Description

[Jack Eidsness]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120406 Firefox/14.0a1
Build ID: 20120406031222

Steps to reproduce:

I have a 3rd party app that uses a lot of textarea fields with a fixed height and wrap="off". Basically they look more like a plain "input" because they're typically one row high. I brought it up in Nightly.


Actual results:

The single row of text is being covered by a horizontal scrollbar. 


Expected results:

Firefox used to figure out that it should show the text instead of hiding it under the scrollbar in this situation but now it can't tell anymore. At first I thought it was misinterpreting the "overflow" value somehow, but the old behavior was a lot like having an invisible or 0-height scrollbar, not like "hidden" or "visible". That is, it would scroll, to follow the cursor, but there was no scrollbar. Can we get that back?

Comment 1

[Jack Eidsness]

Attachment: In release firefox (11) you can read this text. In Nightly (14), it's covered by a scrollbar

There are surely some subtleties to this whole thing I don't yet understand, but I am attaching an HTML file that at least shows the undesired behavior.

I think I ought to make note of the fact that this textarea looks a lot like it would be better off as a <input type="text">. So, I also don't understand why this other site chose to use <textarea> instead of <input type="text" ...> but it's kind of out of my hands. It looks fine in release versions of firefox, but it covers up the text in nightly.

I'm a little concerned about my example because it doesn't show the text the same way in chrome or IE, but somehow my 3rd party intranet site's textarea looks fine in all (release version) browsers that I've tested.

Comment 2

[Alice0775 White]

I can reproduce in
http://hg.mozilla.org/releases/mozilla-aurora/rev/883536e3b5da
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120406 Firefox/13.0a2 ID:20120406042011
http://hg.mozilla.org/mozilla-central/rev/da0d07b5ca1e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120406 Firefox/14.0a1 ID:20120406031222

I can reproduce in Google Chrome 18.0.1025.151 m and IE10.0.8250.0.
I cannot reproduce in Opera11.62 and Firefox12.0.


Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/5e756e59a794
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222190318
Fails:
http://hg.mozilla.org/mozilla-central/rev/15d7708672c1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120223 Firefox/13.0a1 ID:20120223055919
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e756e59a794&tochange=15d7708672c1


Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/90cb54bb0101
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222062519
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/f4e8839c28f5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120222 Firefox/13.0a1 ID:20120222103820
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=90cb54bb0101&tochange=f4e8839c28f5

Suspected :
d82d9b9880a3	Mats Palmgren — Bug 726258 - Don't suppress the scrollbar because of a too small size in the scollbar minor direction. r=bz

Comment 3

[Mats Palmgren (inactive)]

The layout for the testcase is the expected one.  This change is intentional,
for compatibility with Chrome and IE.  Please provide a testcase or public URL
that displays a problem only in Firefox and not in other browsers.  Thanks.

Comment 4

[Jack Eidsness]

It's in an intranet app based on BMC Remedy Mid-Tier. User licenses just to log into it cost money so it will be hard to find a public example.

Also, the app does look more or less ok in chrome, and I took some more time to find out why, now. It only works because in chrome, but not firefox/nightly, this application's javascript knows to work around the horizontal scrollbar covering the text, by setting such elements' style to "overflow: hidden". As a test, I set up a greasemonkey script to try the same workaround in nightly, and there is another problem - "overflow: hidden" in chrome works like an invisible scrollbar (arrow keys and home/end move the text within the box, if it is bigger than the box) and the cursor remains visible. In nightly and firefox, however, the cursor just becomes hidden, as the text never moves. Personally, I wouldn't mind working around this particular app's behavior with a greasemonkey script but since the change you described is in place, it's a catch 22. I can let it hide the text with a scrollbar or hide some of the text with overflow: hidden.

I'd actually tried this before, setting it to "overflow: hidden" and noticed the hidden cursor as a problem, but then convinced myself it wasn't a bug. In the context of the recent change, though, I think maybe it is. What do you think of bug 740866? Maybe I should re-open it?

Comment 5

[Mats Palmgren (inactive)]

Jack, thanks for your investigation.  Bug 356492 will fix scrolling
for overflow:hidden text fields.  Maybe the developers of "BMC Remedy
Mid-Tier" was trying to avoid that bug by using different styles for
Firefox - unfortunately they based the workaround on a bug that is
now fixed (bug 726258).  Anyway, it seems rather odd to use <textarea>
to get a single-line scrollable text field without scrollbars when
there is an element that does exactly that: <input>

Reassigning to TE - please notify "BMC Remedy Mid-Tier" developers
of the problem.

Comment 6

[Adam Stevenson [:adamopenweb]]

Hi Jack. Can you confirm this issue still exists?

Comment 7

[Jack Eidsness]

For better or for worse, I no longer have access to a similar Remedy Mid-Tier installation.
The test case still allows for a scroll bar that covers the entire text area (such that the scroll bar has no value), but I couldn't say whether Remedy's later product offerings ever stopped relying on different behavior.

Comment 8

[Jack Eidsness]

not "test case", I mean the attachment with a tiny textarea.

Comment 9

[Adam Stevenson [:adamopenweb]]

Thanks Jack for your quick response. I'm going to close the bug for now as we have no way of verifying it still exists.

Comment 10

[kingoomieiii]

This issue still exists in BMC Remedy as of 45.0.2.

Sample text box affected by the issue-

<textarea class="text sr " id="arid301398700" cols="20" maxlen="100" style="top: 0px; left: 112px; width: 246px; height: 21px;" rows="1" wrap="off"></textarea>

Comment 11

[Adam Stevenson [:adamopenweb]]

Reopening the bug.

Comment 12

[Adam Stevenson [:adamopenweb]]

There are a few contact options if someone wants to reach out to BMC support. http://www.bmcsoftware.ca/contacts-locations/contact-bmc.html

Comment 13

[Jack Eidsness]

BMC doesn't really have to have anything to do with it. I'm sure BMC users have, out of desperation, written greasemonkey scripts to work around the daily nuisance of their vendor's HTML layout deficiencies, but the example HTML stands on its own legs. Most people wouldn't use textarea for a single line, non-wrapping input, because that's what input type="text" does, by default, but who's to say you can't read it if you do?

<textarea wrap="off"> is the only magic word to induce this behavior, since you can drag to resize any of them that small.

Considering that the other existing choice, other than scrollbars is called "hidden", it doesn't seem like something intentional that in reality, more of the text is literally hidden by the scrollbar than by the "hidden" setting. I would like to propose that the overflow="auto" behavior should revert to "hidden" under a certain height (like the height of a scrollbar + 0.5em). Other than the developer time (which is not to understated), I'm having difficulty imagining what there is to lose by making such a change.

Comment 14

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 15

[Oana Arbuzov [:oanaarbuzov]]

Jack does the issue still reproduce?

Comment 16

[Raul Bucata]

Since the reporter did not respond, I will be closing this, due to lack of additional info. Please feel free to re-open the issue once the issue is confirmed to be reproducible on the latest build of Firefox Nightly.