1998902 - github.com - Blank space on the right side of the page

Status: RESOLVED FIXED

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

Description

[Calin Tanase]

Environment:
Operating system: Android 15
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://github.com/webcompat/web-bugs/milestone/2
2. Observe the page.

Expected Behavior:
The page content fits the entire screen.

Actual Behavior:
Blank space on the right side of the page.

Notes:

• If not reproducible by just accessing the page, try zooming out
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/186370

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce in responsive design mode on desktop. I captured a copy of the page with the Singlefile extension, which also reproduces the bug, and we can create a more reduced testcase from that.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (created with singlefile; view in RDM to see the bug)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (very slightly more reduced)

Comment 5

[Titouan Thibaud [:titouan]]

Attachment: testcase 3

I tried to reduce the case even more. The margin is clearly visible with a red background.

Comment 6

[Titouan Thibaud [:titouan]]

I did some investigation, following those steps:

• Open Fenix
• In Settings, enable Remote debugging via USB
• Load the testcase on Fenix.
• Plug the device into my computer. Open about:debugging on Firefox Desktop
• Find my device in the list of available devices and Click connect
• Select the tab containing the testcase.

This will open the dev tools, that we can further use to investigate.
Disclaimer: I'm not super familiar with webcompat in general, so take those results with a grain of salt.

Results:

• I've found that removing the chips in each row of the table (browser-firefox, os-linux, and so on) does seem to solve the issue.
• Executing this in the console happens to resolve the issue too:

document.documentElement.style.overflowX = "hidden";
document.body.style.overflowX = "hidden";

I'm not sure which conclusion we can get from that, is it somehow helpful?

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Daniel, what are the best next steps here?

Comment 8

[Daniel Holbert [:dholbert]]

Needs more testcase-minimizing/diagnosis to understand the problem. I'll aim to do some of that in the next day or two; leaving ni open.

Comment 9

[Daniel Holbert [:dholbert]]

(And thanks to titouan for the testcase-reducing - I'm sure that'll be helpful!)

Comment 10

[Daniel Holbert [:dholbert]]

This is a targeted workaround that "fixes" it:

      .sr-only { display: none !important }

That sr-only element is a 1px-by-1px element that I think is a tooltip for the "chips", and it has some styles to attempt to make it not paint (notably the clip-path):

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  overflow: hidden;
  clip-path: rect(0 0 0 0);
  overflow-wrap: normal;
  border: 0;
}

...but apparently it does still contribute to layout enough to influence scrollport-size calculations (and cause the viewport to shrink).
(EDIT: and we get its position incorrect due to bug 489100; see below)

Comment 11

[Daniel Holbert [:dholbert]]

I think this is essentially a version of bug 489100; I think part of the issue is that we're positoining that abspos element with respect to a display:inline abspos-containing-block, specifically this in the attached testcase:

<span class="Title-module__trailingBadgesContainer--mijcn">

which has these styles applied in the attached testcase (combined with its default display:inline styling):

.Title-module__trailingBadgesContainer--mijcn {
	overflow: hidden;
	position: relative;
	text-overflow: ellipsis;
	top: 1px;
	vertical-align: top;
}

If I add a style element that gives that class display: inline-block like so....

<style>.Title-module__trailingBadgesContainer--mijcn { display: inline-block }</style>

...then the issue goes away (in the latest testcase as well as the original SingleFile testcase).

That in-and-of-itself isn't really a fix, since it does change the layout (the chips end up linewrapping a bit differently). But it's a nice way to confirm that abspos-in-inline-elements (.sr-only within a span with class Title-module__trailingBadgesContainer--mijcn) is the basic diagnosis here.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 4

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 4 in RDM, in Firefox (top) vs. Chrome (bottom), with Samsung Galaxy S20 Ultra device-profile

Comment 15

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

I see the expected behavior with layout.abspos.fragment-aware-inline-cb.enabled=true (introduced in bug 489100). The page content fits the entire screen in responsive design mode. We'll flip the pref by default in bug 2041551.

Comment 16

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

Reopening the bug and making it depend on bug 2041551.

Comment 17

[Calin Tanase]

Fixed, the issue no longer reproduces.

Tested with:

• Browser / Version: Firefox Nightly 158
• Operating System: Google Pixel 5 (Android 14)