1514637 - Responsive Design Mode should honor OS-level scrollbar setting for textareas

Status: NEW

(DevTools :: Responsive Design Mode, defect, P3)

Description

[stephenmerriman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Create a plain HTML page with a text area, no styling. Inspect it to see it's height. Now activate responsive design mode.


Actual results:

Initially, the textarea is 3 lines tall (47px inner height according to inspector on my computer). In responsive design mode, the textarea shrinks to be 2 lines tall (30px inner height).


Expected results:

The default styling should be the same both in and out of responsive mode.

Comment 1

[u554753]

Hi,

Thanks for reporting this bug. Can you attach a quick test case/sample page so we can inspect this issue further? Thanks!

Comment 2

[stephenmerriman]

Attachment: Minimal test case

Comment 3

[stephenmerriman]

Attachment: Oops, sorry, typo in first one.

Comment 4

[Razvan Caliman [:rcaliman]]

Attachment: textarea size in RDM.mp4

Hi!

I tried to reproduce this both with Firefox (64) Stable and with the latest Firefox Nightly build (66) and can't see the issue on macOS. See video attachment. 

The textarea has the same dimensions in both regular and responsive design mode. There is space for only two lines of content in the textarea in both situations.

Could this be a platform-specific issue?

@Stephen, can you please share a quick video of the issue?

Comment 5

[Brad Werth [:bradwerth]]

I can reproduce on macOS. This may be related to other viewport-related work underway in Bug 1504659.

Comment 6

[stephenmerriman]

Oddly enough, I believe the view in responsive mode may be correct, and is the normal view that is incorrect. If you use the textarea rows="x" format, you will always see x+1 rows normally, and x rows in responsive mode.

Comment 7

[Brad Werth [:bradwerth]]

I can no longer reproduce this. Is it still occurring for you?

Comment 8

[stephenmerriman]

Yes, I'm still getting exactly the same behavior.

Comment 9

[Brad Werth [:bradwerth]]

(In reply to stephenmerriman from comment #8)

Yes, I'm still getting exactly the same behavior.

I'm still not able to reproduce the buggy behavior. Is the bug happening for you in Nightly? If so, please try also in Nightly with a new profile.

If it's still occurring, please attach a screen capture so I can see if there are any special steps I need to take.

Comment 10

[stephenmerriman]

Have just downloaded Nightly for the first time. Here are the results:

https://www.youtube.com/watch?v=ImNhGnYStXE&feature=youtu.be&hd=1

Comment 11

[Brad Werth [:bradwerth]]

Attachment: textarea_report_rows.html

Please try loading this attachment. Based on your screen recording, I think you will be seeing these results:

Before RDM) Textarea rows = 3
After RDM) Textarea rows = 2

If that's what's happening, then we've got some kind of style substitution happening in your browser on the initial load. The default rows for a textarea in Firefox is 2, and that's what you should be getting on the initial load.

Also, testing with a clean profile requires you to create a new profile. Nightly will use the same profile you were already using. Here's how to create an use a new, clean profile: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiple_profiles

Comment 12

[stephenmerriman]

No, it says 2 both times.

The very first page of Nightly (seen in video) says "This installation of Nightly has a new profile.", and I can confirm it wasn't using the same profile as normal.

However, have created another new profile, with exactly the same results.

Comment 13

[Brad Werth [:bradwerth]]

Thank you for your patience. Okay, looking more carefully at your recording, when you are leaving RDM mode, I can see the textarea snap to a slightly larger size which is then the size of the textarea shown in the regular window. The difference in area is not proportional. It's about the same amount added to both the height and width. That indicates to me that this is related to your OS-level scrollbar settings (which of course aren't affected by Firefox profiles).

On macOS, when I switch my scrollbar preferences to be always displayed, I get the same behavior as you are getting. This is why I was able to replicate the bug some time ago. I've since switched my scrollbar settings and therefore couldn't reproduce it. I don't know exactly what the Windows preference setting looks like, but there's probably a way for you to choose overlay scrollbars which will give you a 2 row textarea initially.

I'll update my attachment to make this more clear. The update will set overflow: auto and wrap=off. That will show the vertical scrollbar in Firefox, and both scrollbars in Chrome.

Regardless of the cause, certainly RDM should display the text area in the same way. It appears that RDM is forcing overlay scrollbars for textareas. I've retitled the bug to make the issue more explicit.

Comment 14

[Brad Werth [:bradwerth]]

Attachment: textarea_report_rows.html

Comment 15

[Micah [:mtigley] (she/her)]

Looking into this as I'm currently working Bug 1509202, whose issue is very similar to this. Although I believe the one potential fix for this may be easier.

When RDM's content frame script is started, we apply a stylesheet to the document that will show overlay scrollbars for all elements, except for <select>. This explains why overlay scrollbars are being forced on <textarea>, so solving this particular issue may be as simple as including it to the :*not() selector list.

Comment 16

[Micah [:mtigley] (she/her)]

Attachment: Bug 1514637 - Add the ability to toggle overlay scrollbars in RDM.

Comment 17

[Brad Werth [:bradwerth]]

(In reply to Micah Tigley [:mtigley] from comment #15)

Looking into this as I'm currently working Bug 1509202, whose issue is very similar to this. Although I believe the one potential fix for this may be easier.

When RDM's content frame script is started, we apply a stylesheet to the document that will show overlay scrollbars for all elements, except for <select>. This explains why overlay scrollbars are being forced on <textarea>, so solving this particular issue may be as simple as including it to the :*not() selector list.

This sounds like the right fix. I think we need to consider making this behavior (forced overlay vs not) toggle-able in RDM. Here's my reasoning: often users want to simulate a mobile device, in which case imposing overlay scrollbars is appropriate. But occasionally they just want to see their content at different window sizes, in which case we should honor the OS-level scrollbar preference. We need to keep both use cases viable. I think the most sensible way to do it is to add an additional override behavior to our "Touch Simulation" UI widget. When that widget is on, then overlay scrollbars are forced on. When it is off, we display textarea scrollbars as the OS settings dictate.

Doing this will require changes to several code areas, including manager.js updateTouchSimulation(), and in nsDocShell. The style toggle could be accomplished, I suppose, with an additional "!important" style declaration for the forced overlay scrollbars. So I think attachment 9071698 [details] will be part of the solution, but not enough to support all use cases.

Comment 18

[Micah [:mtigley] (she/her)]

But occasionally they just want to see their content at different window sizes, in which case we should honor the OS-level scrollbar preference. We need to keep both use cases viable. I think the most sensible way to do it is to add an additional override behavior to our "Touch Simulation" UI widget. When that widget is on, then overlay scrollbars are forced on. When it is off, we display textarea scrollbars as the OS settings dictate.

This a good point. I jumped ahead of myself assuming a fix that's really only appropriate for mobile devices. And I agree toggling the overlay scrollbars in the Touch Simulator is the best place the put this. I'll update the above patch to include this solution.