1887163 - Left margin of article is too narrow/missing in Fenix Nightly vs. Chrome

Status: NEW

(Firefox for Android :: Browser Engine, defect, P3)

Description

[Andrew Overholt [:overholt]]

Attachment: Screenshot 2024-03-22 at 3.56.21 PM.png

The text of https://www.cnbc.com/2024/03/14/finland-psychologist-happiness-researcher-phrases-we-use-every-day.html?utm_source=pocket-newtab-android appears very close to the left side of my screen in Nightly for Android as compared with Chrome on the same device.

• Firefox version: 125
• Android device model: Samsung Galaxy A54
• Android OS version: 14

Comment 1

[Jonathan Kew [:jfkthame]]

The page has a style block:

.PageBuilder-styles-makeit-col--YrNLU {
  display: flex;
  flex-direction: column;
  flex-grow: 0;
  flex-shrink: 0;
  margin-right: 30px;
  max-width: calc(100% - 30px);
  min-width: calc(100% - 30px);
}

that gives the content a right margin but no left margin, which corresponds to what I see in your screenshot.

However, it also has:

@media (min-width: 360px) and (max-width: 759px) {
  .PageBuilder-styles-makeit-col--YrNLU {
    margin-left: auto !important;
    margin-right: auto !important;
    max-width: 100% !important;
    min-width: 100% !important;
  }
}

which should override those margins, and at the same time:

@media (min-width: 360px) and (max-width: 759px) {
  .PageBuilder-styles-makeit-pageRow--g0cVX.PageBuilder-styles-makeit-containerFluidWidths--LhoYP {
    padding: 0 20px;
  }
}

provides padding on both sides of its containing <div>.

I suspect that for some reason, those blocks aren't active for you, and so you're seeing the no-left-margin version.

What's the screen size and CSS-to-device pixel scale factor of your device? According to Samsung's site, it appears to be a 1080 x 2340 panel; if window.devicePixelRatio is 3, that would be a width of exactly 360 px, which is right on the edge of the range for those @media queries. So maybe there's an arithmetical inaccuracy somewhere in handling the scale that causes it not to match? Strange, though, since assuming devicePixelRatio is 3.0, we should be able to do either 360 * 3 or 1080 / 3 without getting into fractional values that might lose precision.

So I don't think this is really a Layout: Text issue; it's either a problem with the CSS computations involved in those media queries, or else maybe it's an issue with the Android platform integration resulting in slightly incorrect values going into those computations.

Comment 2

[Jonathan Kew [:jfkthame]]

I tried to look into this in an emulator configured to have the same screen size as the Galaxy A54 (as best as I could tell), where the display is 1080 pixels wide with a devicePixelRatio of 3, so that we have 360px of width from a CSS point of view, but the problem doesn't reproduce for me; the @media blocks with min-width: 360px get applied as expected, and the content has margins on both sides.

So I guess it may require debugging on an actual device to figure out what's going on here?

Comment 3

[Kaya [:kaya]]

I've tried to replicate the screen specs of A54 on an emulator as :jfkthame did, but I also could not reproduce the issue. I did try several other screen resolutions in addition to the factory specs but had no luck. At this point, I agree that we would need a physical device to reproduce the issue and debug the issue with that.

Comment 4

[Joe Walker [:jwalker]]

I just spent a few mins looking at this problem with Andrew and his phone (we got side-tracked, sorry!). Unfortunately I don't have the exact numbers committed to memory, I'm fairly sure that documentElement.clientWidth was significantly lower in Firefox than in Chrome - i.e. more than a rounding error lower. Could devicePixelRatio be significantly different? Would it help to know the results of the following in Firefox and Chrome?

data:text/html,<script>document.write(`devicePixelRatio=${window.devicePixelRatio}<br/>clientWidth=${document.documentElement.clientWidth}`);</script>

Now I'll stop pretending to be an engineer and go back to editing my powerpoint doc.

Comment 5

[Andrew Overholt [:overholt]]

browsersize.com reports a "Screen size" of 342x741 in Firefox and 384x832 in Chrome on my phone.

Joe noticed if you use responsive design mode to make your window < 360 pixels wide, the problem occurs on desktop, too.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Andrew Overholt [:overholt] from comment #5)

browsersize.com reports a "Screen size" of 342x741 in Firefox and 384x832 in Chrome on my phone.

That would imply a devicePixelRatio of 1080/342 (or 2340/741) which is 3.157894736842105. That's a kinda weird value! Though interestingly, it seems to be exactly 3 / 0.95, suggesting that there's some kind of inverse-95%-scaling going on.

Chrome's ratio, for comparison, is 2.8125.

(It would be nice to confirm whether asking the browsers for window.devicePixelRatio does indeed report these values.)

Do we have a global scaling factor in the Android app that might be applying to the entire screen? If there's an "enlarge everything" kind of option (e.g. in preferences), that might work by effectively scaling the devicePixelRatio and could be causing this effect.

If it's not some kind of (perhaps unknowingly) customized setting like that, then it's looking to me like this is an issue with the Android platform support, not really a core Gecko bug; I think Gecko is behaving "correctly" based on the screen details it's receiving.

It looks like the MakePrimaryScreen() function here is responsible for getting screen dimensions and density from the java side. It would be interesting to see what this retrieves for bounds, density, and dpi.

Joe noticed if you use responsive design mode to make your window < 360 pixels wide, the problem occurs on desktop, too.

Indeed; that's the result of the @media (min-width: 360px) etc blocks in their CSS. So I think the narrow (non-existent) left margin is "working as designed" for narrow screen widths (it may be a design error, but the same thing happens in Chrome or Safari given a sufficiently narrow window). The question is why we're coming up with such a small size (or, equivalently, unexpectedly high devicePixelRatio).

I'm moving this to the Fenix product, as I think it's quite specifically about the integration with the Android platform, and those folks will have a better understanding of the pieces involved there.

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Joe Walker [:jwalker] from comment #4)

data:text/html,<script>document.write(`devicePixelRatio=${window.devicePixelRatio}<br/>clientWidth=${document.documentElement.clientWidth}`);</script>

FWIW (and this is exactly what Jonathan noted above but I'll put it here for posterity from the device):

Nightly:
devicePixelRatio=3.1578947368421053
clientWidth=887

Chrome:
devicePixelRatio=2.8125
clientWidth=980

Comment 8

[Andrew Overholt [:overholt]]

Disabling Automatic font sizing (three dots > Settings > Accessibility) seems to fix it

Comment 9

[Emilio Cobos Álvarez [:emilio]]

That means that we're trying to honor your system font size a11y settings by default (and zooming the page) which causes this.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Chrome doesn't do that by default afaict.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Ok, so this is because Firefox is honoring the font-size setting from the OS by default. Some more context exists in:

• bug 1850808 and dependent bugs.
• bug 1845917 comment 5

Chrome doesn't do any of that by default, and maybe we should be consistent. I'll comment with a concrete proposal.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:bclark, could you have a look please?

For more information, please visit BugBot documentation.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Fenix::Browser Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.