[Preconditions]:

• Use a MacBook Pro (13-inch) or MacBook Air (11-inch)

[Affected versions]:

• 68.0a1 (20190516215643)
• 68.0b2 Dev Edition(20190516152822)
• 67.0 (20190516215225)

[Affected platforms]:

• macOS 10.14

[Steps to reproduce]:

1. Go to https://mail.google.com/ and login
2. Click on the Compose button
3. Click on the Insert link button
4. Switch between Web address and Email address checkboxes

[Expected result]:

• The horizontal scrollbar is displayed, no visual glitch is triggered.

[Actual result]:

• The horizontal scrollbar flickers and then disappears.

[Regression range]:

• Issue reproducible on Fx 55.0a1. I will provide more information asap.

[Additional Notes]:

• This issue was not reproducible using the same test machine with macOS 10.13.6.
• Changing the resolution didn’t make any difference.
• I couldn’t reproduce the issue on iMac (21.5 inch).

I can reproduce this issue only way back to Fx 51.0a1, earlier versions are broken or Gmail page is not compatible with the mentioned above steps.

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #0)

[Expected result]:

• The horizontal scrollbar is displayed, no visual glitch is triggered.

[Actual result]:

• The horizontal scrollbar flickers and then disappears.

The scrollbar appears because they're (re)creating content inside a scrollable area that overflows.

The scrollbar disappears because that's just the way that "native" scrollbars behave on Mac by default, per e.g.
https://www.nytimes.com/2017/02/02/technology/personaltech/solving-the-case-of-the-disappearing-scroll-bars.html
On my linux machine, the scrollbar appears and stays visible.

In Chrome on Linux, I can confirm that there are no scrollbars (the content doesn't overflow), but I'll bet that's just because of differences between Firefox vs. Chrome testcase.

So I think this is basically just a minor webcompat issue, where Gmail folks could avoid the presence of overflow by sizing this content a bit more carefully so as not to depend on Chrome-specific widget sizing.

In particular, GMail has this styling (in Firefox):

<input id="linkdialog-onweb-tab-input" class="LW-Ke-JD-LV-J7" aria-labelledby="linkdialog-onweb" type="url"
    style="width: 416px;">

...inside of a div that is 410px wide. If I remove the explicit 416px width, then the input element fits and there's no overflow / no scrollbar.

FWIW here's a test that shows how Firefox will show overlay scrollbars when overflowing content is created, while Chrome does not.

In Chrome, the input element from comment 3 (the "web address" textbox) instead has style="width: 406px;" -- 10px smaller than the specified width that Gmail puts on this element for Firefox.

I don't know how they're coming up with that specified width, but that's the root of the problem here. We should reach out and see if they can give us style=width:406px as well to avoid this awkward/unnecessary overflow.

Stephen, for the test case in comment 4, is it expected (according to macOS HIG) that the overlay scrollbars show up when new overflowing content is available?

(In reply to Cameron McCormack (:heycam) from comment #6)

Stephen, for the test case in comment 4, is it expected (according to macOS HIG) that the overlay scrollbars show up when new overflowing content is available?

Based on Safari's and Chrome's behavior, I'm tempted to say no. If memory serves me right, this was added to make it clear in dropdown menus when more options are available than what's displayed when first opened (i.e. the dropdown menu can be scrolled). We may have to be more fine-grained and only do this for dropdown menus.

It seems like there's been some change:

<input id="linkdialog-onweb-tab-input" class="LW-Ke-JD-LV-J7" aria-labelledby="linkdialog-onweb" type="url" style="width: 410px;">

It's now width: 410px (maybe that value just depends on my monitor or something)?

This is pretty minor, but we could ship an intervention here. But let's reach out as well.

This appears to be fixed by Google, see the attached screenshot. I also can no longer find inline-styles on that element.

Anca, can you confirm this is fixed? :)

Checked with 78.0, 79.0a1 (2020-06-25) with macOS 10.15.5 - MacBook Pro (13-inch).
The issue does not appear to manifest.

Confirmed that this issue is no longer reproducible on macOS 10.14 and may have been fixed by Google (Verified using Firefox 79.0a1 & an old Firefox 67.0).

Marking this as WORKSFORME based on this & comment 10.