User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Create <input type="text"/> with writing-mode: vertical-lr or vertical-rl, fill with some text.

Actual results:

Vertical text input is displayed, but text inside abuts beginning (top) and end (bottom) of input box without any padding (horizontal text input has 8px padding between text and beginning and end (left/right) of input box)

Expected results:

Vertical text input box should match horizontal text input box, and have 8px padding between text and beginning/end of input box.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Hi benayang,

Thanks for your bug report. I create a test in https://jsfiddle.net/cuwvy5k1/, but I cannot observe the missing padding in the vertical <input> box. Could you attach your test case, please? It'll help us identify the issue.

Hi Ting-Yu Lin,

I'm getting the same problem with your test. Note that there is padding before (to the left) of the "1" for the horizontal input box, but no padding before (to the top) of the "1" for the vertical input boxes.

Here's my own test as well in case you wanted to see it: https://codepen.io/iwsfutcmd/pen/BaaoJNw

I'm experiencing this on Firefox 70.0b14 64-bit on Ubuntu.

Note: I just tested this on my phone, and there does not appear to be an issue. It's running Firefox for Android 68.2b5

Thanks,
Ben

I'm on Linux Mint, which is based on Ubuntu 18.04. I can reproduce this issue with Firefox 69 installed by the system with a fresh profile.

The appearance of <input> can be themed by gtk. I notice that the profile created by the system firefox will insert a preference "widget.content.gtk-theme-override" with a string value "#" where the firefox download from mozilla.org won't.

You can check if you have the "widget.content.gtk-theme-override" set to some value.

1. Type "about:config" in the url bar.
2. Acknowledge the warning.
3. Search for "widget.content.gtk-theme-override".

I attached my screenshot with no "widget.content.gtk-theme-override" set. The padding looks normal on the vertical <input>.

I wonder what else can we do here. Move the component to gtk to gain some attention.

Hmm, I don't seem to have widget.content.gtk-theme-override in my about:config at all.

I'm on Ubuntu 19.04, but for the record, this version of Firefox is coming from the "FIrefox Beta" PPA (https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next).

I tried adding it (both as default, and as a value of ""), and no change.

You will need to restart Firefox after changing widget.content.gtk-theme-override.

Tried restarting Firefox after setting widget.content.gtk-theme-override to an empty string, "", and # for good measure. No change.

Just checked the "Layout" section of "Inspect Element" on each of the inputs. It's showing a padding of 1px on all four sides, and a border of 8px on the left and right side for all of them.

I turned on the "Show Browser Styles" setting so I could see the user agent CSS, but nothing in there indicates there should be an 8px border anywhere. Is it being set somewhere the inspector can't see?

Thanks again for looking into this, btw.

benayang,

I get your actual result (your screen shot in comment 3) while using Firefox 68.5.0 ESR under Linux Debian 10.3.
I think you found a valid bug.
The padding and border declarations for text input seem to not have been logicalized.
resource://gre-resources/forms.css states that

input {
-moz-appearance: textfield;
/* The sum of border and padding on block-start and block-end
must be the same here (...) */
(...)
}

Here's my solution:

input[type="text"]
{
border-inline-start: ThreeDLightShadow inset 2px;
padding-inline-start: 8px;
padding-inline-end: 8px;
padding-block-start: 0px;
padding-block-end: 0px;
}

and here's what it would do in your (slightly modified, customized) test:

http://www.gtalbot.org/BugzillaSection/Bug1587953-padding-inline-start-for-input-text.html

and the gap (or spacing) between the start border and "1" is consistent and the same for all 3 text inputs while using Firefox 68.5.0 ESR and Firefox 75.0a1 buildID=20200306201041 . If you increase (or decrease) 'padding-inline-start' with Inspector tool, then the gap (or spacing) between the start border and "1" in all 3 inputs are rendered consistently and as expected.

I do not believe that Widget: GTK is the correct component.
We need to verify if the layout issue also exists in non-Linux platforms/environments.

A bug report like bug 1385211 was filed under Layout: Form Controls. So, I am going to do the same here.
The only remaining thing to do is to have a Window user (and/or a Mac OS user) confirms that (s)he sees/gets a layout like your screen shot in comment 3.

I checked on macOS, and I do not see the issue here; the padding before the text of the <input> looks the same in vertical and horizontal modes.

(In reply to benayang from comment #8)

Just checked the "Layout" section of "Inspect Element" on each of the inputs. It's showing a padding of 1px on all four sides, and a border of 8px on the left and right side for all of them.

I turned on the "Show Browser Styles" setting so I could see the user agent CSS, but nothing in there indicates there should be an 8px border anywhere. Is it being set somewhere the inspector can't see?

On macOS, the Inspector shows that there's a uniform 1px padding on all sides, and 3px border. No 8px anywhere, and no vertical/horizontal difference.

I think the key question here is to determine where that 8px is coming from in the Linux case. I guess it must be related to the Gtk theme; and whether widget.content.gtk-theme-override is relevant may depend on what the default/current theme is set to. So I think this is in fact a Widget-level issue specific to Gtk, not a Layout bug.

I have modified

http://www.gtalbot.org/BugzillaSection/Bug1587953-padding-inline-start-for-input-text.html

and now only use

input[type="text"]
{
border-inline-start: ThreeDLightShadow inset 2px;
padding-inline-start: 8px;
}

which suffices to reproduce the issue.

On macOS

I would be nice to know what Windows users see or get with our tests.

to determine where that 8px is coming from in the Linux case.

I agree. The layout panel (I am not sure of the exact name for this in English) indicates that border-left-width increases inexplicably and unexpectedly from 2px to 8px.

what the default/current theme is set to

If that can help: I have Clearlooks for GTK2 theme and Adwaita for GTK3 theme.

Additional steps to reproduce:

Load
http://www.gtalbot.org/BugzillaSection/Bug1587953-padding-inline-start-for-input-text.html

Select the horizontal input in Inspector tool

In the Layout panel (box model), the border-left-width is 2px and in the Computed panel, the border-left-width is also 2px.

Now, (the order of unchecking is important) uncheck the border-inline-start declaration checkbox and then uncheck the padding-inline-start declaration. And now, the border-left-width unexpectedly will jump from 2px to 8px in the Layout panel (box model). Once refreshed, the Computed panel will also indicate that the border-left-width has unexpectedly jumped from 2px to 8px.

I can upload a screen shot if required.

On my Ubuntu machine, I see a slight discrepancy, such that the horizontal <input> has a little more space before the text than appears in the vertical version. This happens because (with the particular theme I have) the border-left (and -right) width is 7px, whereas the border-top and -bottom is only 5px. (There's 1px padding on all sides.) So there's a 2px difference, and these border widths don't swap when vertical writing mode is applied. It's not terribly obvious, but is visible when you consciously look for it.

I have a patch that I think should improve the behavior here. If you could try the build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=c11ab40cb6830ec440fa52530b6bd6faaad05419 and confirm whether it resolves the problem, that would be great -- thanks!

(To run the test build, download https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FJJbJ4WjSPCtfJ_USxSiuw/runs/0/artifacts/public/build/target.tar.bz2, unarchive it, and then run firefox directly from the resulting folder.)

Jonathan, I downloaded your test build, followed your instructions, then tried
https://codepen.io/iwsfutcmd/pen/BaaoJNw
and my test in your test build (and with a new profile) and this seems to resolve the padding-inline-start and border-inline-start issue. Bravo!
Thank you!

Thanks for testing, Gérard.

(I suspect there could be other similar issues that may show up with other widgets/themes, but I'm reluctant to try and pre-emptively add vertical-mode adjustments in lots of places without having seen specific testcases, so for now the patch is limited to the particular values that are relevant to this example.)

Backed out changeset b8205184278a (bug 1587953) for crashtests/1547420-1.html

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Csuperseded%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=linux%2C18.04%2Cx64%2Cquantumrender%2Cdebug%2Creftests%2Ctest-linux1804-64-qr%2Fdebug-crashtest-e10s%2Cr%28c%29&fromchange=026c69cf6e3abe6c53206497efa4d40f8d788cf1&selectedJob=293900616

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293900616&repo=autoland&lineNumber=61401

Backout: https://hg.mozilla.org/integration/autoland/rev/c23a777240a07b73dd6e1a844fb981bb333b168d

https://hg.mozilla.org/mozilla-central/rev/819fa64e4fe4