Closed Bug 1757917 Opened 2 years ago Closed 2 years ago

Part of "Browse" menu becomes displayed on wtol.com with ETP enabled

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
Firefox 99
Platform:
ARM64
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
101 Branch
Tracking Flags:
Tracking Status
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- fixed

People

(Reporter: oanaarbuzov, Assigned: twisniewski)

References

(
URL
)

Details

Attachments

(6 files)

ETPDisabledvsenabled.png
321.18 KB, image/png
Details
testcase 1 (broken in all mobile browsers)
491 bytes, text/html
Details
screenshot of the same issue in Chrome on Desktop in responsive design mode
114.11 KB, image/png
Details
screenshot of expected rendering (focusing on ad iframe inside of #front_atf), taken with tracking protection disabled
300.39 KB, image/png
Details
screenshot of buggy rendering ((focusing on ad iframe inside of #front_atf), taken with tracking protection enabled
300.07 KB, image/png
Details
Bug 1757917 - Improve the styling applied to iframes injected by the SmartBlock shim for Google Publisher Tags to prevent conflicts with some websites; r?denschub
48 bytes, text/x-phabricator-request
Details | Review

Environment:
Browser / Version: Firefox Focus Release 98.1.0 (🦎 97.0.1-20220228162945), Firefox Focus Nightly 99.0a1 (🦎 99.0a1-20220302065857)
Operating System: Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

Prerequisites:
ETP enabled.

Steps to reproduce:

  1. Navigate to https://www.wtol.com/
  2. Observe the page after a few seconds (5-10s)

Expected Behavior:
"Browse" menu is not automatically displayed unless manually triggered.

Actual Behavior:
Part of "Browse" menu becomes displayed.

Notes:

  1. Screenshot attached.
  2. The issue is not reproducible with ETP - disabled
  3. The issue is not reproducible on Firefox Nightly normal or private mode.

This isn't specific to Focus or private-browsing, it reproduces for me in Fenix nightly as well on my phone.

It appears to be some weird webcompat issue that only triggers on Android.

This inline CSS is un-hiding their page's site menu:

[data-platform="mobile"] .header__nav {
    display: flex;
    flex-direction: column;
    position: fixed;
    margin: 0;
    padding: 0;
    top: 50px;
    left: -100vw;
    bottom: 0;
    width: 100%;
    overflow-y: auto;
    // etc, including a CSS transition to animate the menu when it opens

That CSS, and the data-platform, are both hard-coded in the markup:

<html class="root root_js_disabled" lang="en-US" data-version="2.6.2.1" data-platform="mobile">

But for whatever reason the site's menu isn't appearing in the responsive design mode on desktop, when using the Fenix UA string. It does have the same data-platform="mobile" and CSS, but the header__nav element has a zero height there.

@dholbert, since there is no height specified on the element, I'm surprised to see it being given one at all. Is there any reason why a flex-item would be given a height on Fenix, but not responsive design mode? I've tried disabling visual-viewport in about:config, but the issue still persists.

No longer blocks: tp-breakage
Component: Privacy: Anti-Tracking → Mobile
Flags: needinfo?(dholbert)
Product: Core → Web Compatibility

(In reply to Thomas Wisniewski [:twisniewski] from comment #1)

This isn't specific to Focus or private-browsing, it reproduces for me in Fenix nightly as well on my phone.

Hmm -- in my case, it only reproduces in Focus. Can't repro (yet) in Firefox Nightly. Tried with default ETP settings as well as Strict, with uBlock origin enabled and disabled. Also tried in Private Browsing mode, for good measure. Unable to repro in Firefox Nightly (on Android) under any of those conditions, but I can reliably repro in Focus.

@dholbert, since there is no height specified on the element, I'm surprised to see it being given one at all.

The height here comes from these lines of CSS in your quoted CSS rule:

    position: fixed;
    top: 50px;
    bottom: 0;

For position:fixed/absolute elements, if you set both offsets in an axis (top and bottom in this case), then the height is whatever space is left when applying those offsets to the containing block (the viewport in this case).

Is there any reason why a flex-item would be given a height on Fenix, but not responsive design mode?

(Terminology nit: display:flex makes this a flex container, not a flex item.)

On the actual substance of the question: I don't think that's actually what's happening. In desktop-RDM on my end, it looks like the element does have a nonzero height, but it's just positioned sufficiently-far-offscreen to the left to be invisible.

If I add border: 3px solid pink; to that element, then I can see the right edge of its border barely pushing onscreen (in RDM on desktop), with a nearly-full-viewport height. So the height isn't the problem -- it's the horizontal position and/or width.

Moreover: if you hide this element by giving it display:none, the rest of the document seems to be awkwardly zoomed/positioned here for some reason, such that the right ~third of the screen is blank.

My guess here is that some invisible piece of content is appearing offscreen to the right and causing the viewport to be rescaled for some reason, such that the right part of the screen ends up blank and the left: -100vw ends up unsuccessfully-pushing-the-menu-offscreen.

(In reply to Daniel Holbert [:dholbert] from comment #2)

My guess here is that some invisible piece of content is appearing offscreen to the right and causing the viewport to be rescaled for some reason

Specifically this is an element whose ID starts with google_ads_iframe (there are several such elements, I'm not yet sure if they're all problematic or just some of them).

And they're dangerously close to the right edge of the screen because they are inside an element with class="ad" which has text-align:center. If you untick that style, then the issue goes away (because the iframe's origin moves from the center of the screen to the left of the screen, which makes it less likely to overflow).

More digging later on... not yet sure why "good" configurations end up avoiding this issue (especially Chrome and Firefox Nightly on the same device in my case).

Here's a reduced testcase to demonstrate what's happening here -- though this is broken on all mobile browsers (not just Firefox). I think Focus is ending up receiving content that's like this testcase, whereas other browsers are not, for some reason.

This testcase has a teal fixed-pos element with left: -100vw which is initially offscreen; but then some content is dynamically added which overflows off the right side of the viewport, and that causes the left: -100vw thing to appear onscreen to some extent.

As I said: with this testcase, this happens in Firefox and Focus and Chrome on Android (and in RDM on desktop Firefox as well). So I think this is a minimization of the bad "end state" rather than being a minimization of the site itself.

Flags: needinfo?(dholbert)

Looks like there are a family of news stations that are all affected.

bug 1758146 was filed for this same issue on 12newsnow.com ; and that site as well as this bug's site (wtol.com) have this same pattern near the top of their source:

    <link rel="preconnect" href="//media.wbir.com">
    <link rel="preconnect" href="//interactive.wbir.com">

which was a hint that https://www.wbir.com is in the same family and also affected (I loaded it in Focus and confirmed that it is affected).

I think this family of news sites are under the "Tegna" umbrella (identified in part by window.performance.mark("tegna_server_response"); at the top of their source).

There's a carousel of these sites at https://www.tegna.com/brands/ ("64 Local News Brands in 51 Markets") -- I didn't click through to all of them, but the ones I clicked all seem to use the same design, & presumably they're all affected.

Here's a sample of those:
https://www.12news.com/
https://www.9news.com/
https://www.kagstv.com/
https://www.kens5.com/
https://www.ksdk.com/
https://www.ktvb.com/
https://www.newswest9.com/
https://www.wcnc.com/

(In reply to Daniel Holbert [:dholbert] from comment #2)

(In reply to Thomas Wisniewski [:twisniewski] from comment #1)

This isn't specific to Focus or private-browsing, it reproduces for me in Fenix nightly as well on my phone.

Hmm -- in my case, it only reproduces in Focus. Can't repro (yet) in Firefox Nightly. Tried with default ETP settings as well as Strict, with uBlock origin enabled and disabled. Also tried in Private Browsing mode, for good measure. Unable to repro in Firefox Nightly (on Android) under any of those conditions, but I can reliably repro in Focus.

Interestingly, I can reproduce in Firefox release on the same device (Pixel 4a), though only if I enable Strict tracking protection.

I can also repro on a different older device (an old Pixel 2) with Firefox release and Nightly, again only if I enable Strict tracking protection.

I also once briefly reproduced the issue on that older phone, under default tracking protection settings (not strict) -- i.e. I loaded the page and let it sit, and all of a sudden the hamburger menu overlapped the screen -- but it went away after a second or so.

This leads me to believe that the site has some JS that it expects to run, to hide (or shrink) the aforementioned offscreen-to-the-right ad iframes, and that script is being blocked with strict ETP settings, which is what's causing the issue here.

Aha, "good news", I can also reproduce in Firefox Nightly 100.0a1 (2022-03-10) on Desktop, under Responsive Design mode, if I enable strict tracking protection.

Actually, I just reproduced this at https://www.wtol.com/ in responsive design mode on Nightly 100.0a1 (2022-03-11) (64-bit) on Linux desktop, without needing strict tracking protection. I even repro'd it under our most-permissive "Custom" tracking-protection settings, with all forms of protection unchecked.

I did, however, need the following:
(1) To get their mobile layout, I needed "Android" or "iPhone" in the UA string (literally just a UA string of Android or iPhone is fine, typed in manually at the top of RDM UI).

(2) To get the offscreen content to impact the viewport, touch emulation needs to be active (the little "finger" button at top right of RDM UI).

(3) My viewport has to be < 320px wide (e.g. 250px is good) in order for the hamburger menu to be visible. (It has to be skinny in order for the overflowing piece of the hamburger menu to show up.)

In fact, I can reproduce in Chrome's responsive design mode on Desktop if I make my viewport 250px wide. I'll attach a screenshot showing that.

So: it seems like any touch-enabled mobile browser with a ~300px-wide-or-less viewport will run into a version of this issue -- this isn't a wholly Firefox-specific problem.

So, now it's a question of "why does this general problem happen for Focus and Firefox (release version at least) on Android with default configuration, but not Chrome on the same device?"

Here's a screenshot showing the issue in Chrome-for-Desktop.

It seems to be happening there because something is making the fixed-position viewport be at least 320px wide, and so the width:100% fixed-pos hamburger menu ends up being 320px wide, but it's positioned only 100vw off the left side of the screen which in this case is however-wide-the-screen-resolution-is. So if the screen resolution is less than 320px, then some of the hamburger menu leaks onscreen.

(In reply to Daniel Holbert [:dholbert] from comment #11)

It seems to be happening there because something is making the fixed-position viewport be at least 320px wide, and so the width:100% fixed-pos hamburger menu ends up being 320px wide, but it's positioned only 100vw off the left side of the screen which in this case is however-wide-the-screen-resolution-is. So if the screen resolution is less than 320px, then some of the hamburger menu leaks onscreen.

(Note that the conditions for this Chrome screenshot are a bit contrived, since 320px is a pretty small width -- smaller than the width of a typical phone screen -- which is why this isn't reproducible in Chrome on Android on a typical device.)

The tracking-protection connection here is: with strict tracking protection, it seems that the centered iframe that I referenced in comment 3 runs off the side of the screen and causes the fixed-position viewport to be substantially wider (not just 320px wide but 50vw + 300px wide, since the overflowing iframe is centered using text-align:center (i.e. positioned at 50vw in this case), and is 300px wide) -- so e.g. if you have a 400px-wide screen, then the iframe will cause your fixed-position viewport to be 200+300px = 500px wide, which is 100px wider than your screen size, which causes the hamburger menu also be 500px wide, and then it leaks onscreen by 100px since it's positioned at left:-100vw which is -400px.

My suspicion is that there's some script or event which normally results in this ad iframe being resized or repositioned so that it doesn't overflow so much, and that script gets blocked by ETP.

Yeah, so specifically the issue is that, when strict tracking protection is enabled (and maybe just at-pageload-until-tracking-scripts-are-loaded?), the page gives these iframes position:absolute. They're inside of a text-align:center element, which would normally center the whole 300px width of the iframe in the container; but position:absolute makes us center its origin instead, and place the iframe's origin halfway across the screen (which makes it likely to run offscreen).

(Some other ad-iframes get positioned even further to the right, too; not all of them are centered. But for all of them that run offscreen with ETP, they do so because they're position:absolute and hence are laid out as if they were 0x0 and then are allowed to overflow.)

Here's a screenshot of the page in Firefox Nightly with default tracking-protection settings, at 400px-wide viewport (so not susceptible to the trivial 320px-or-smaller issue discussed above).

I've added a 1px red border around the iframe so that you can see where it is -- it's the FILA ad. And you can see its styling in devtools -- it does not have position:absolute.

Attachment #9267480 - Attachment description: screenshot of ad iframe inside of #front_atf, with expected stlyling and rendering (note: no position:absolute) → screenshot of expected rendering (focusing on ad iframe inside of #front_atf), taken with tracking protection disabled

For comparison, here's a screenshot with tracking protection strict (specifically "Custom" tracking settings, with only "Tracking content" blocked, "In all windows" (not just private windows)).

I'm focusing on the same iframe (inside of #front_atf) and, as in my previous screenshot, I've added a 1px solid red border around this iframe so you can visualize it. I've also made the hamburger menu partially transparent so that it doesn't entirely block you from seeing the page.

Things to notice, when comparing with the previous screenshot:

  • The iframe is empty (it is indeed an ad that is getting blocked from setting itself up).
  • In this broken screenshot, the iframe has position:absolute in its inline style.
  • This absolute positioning (combined with the text-align:center on its container and the fact that it doesn't have an explicit left specified) is what makes it run off the right edge of the screen and cause this layout problem.

So: tl;dr, the page makes some style changes via some script that is getting blocked by Tracking Protection (if you have "strict" or just "tracking content: all windows"), and those style changes are required in order for the page to lay out properly.

When the script is blocked, the "stub" ad iframes (like the one I screenshotted above in comment 15) are left with inline style attributes that inadvertently make them run offscreen, which inflates the viewport and breaks the layout such that e.g. the hamburger menu's offscreen position is no-longer-fully-offscreen.

Thanks so much, Dan!

Funny enough, the iframes in question are replacements that are being handled by SmartBlock, we just need to tweak this line in the shim to fix this: https://searchfox.org/mozilla-central/source/browser/extensions/webcompat/shims/google-publisher-tags.js#50

It seems to be enough to add dimensions (and while there we might as well drop the erroneous unset:all):

      f.style = "position:absolute; width:0; height:0; left:0; right:0; z-index:-1; border:0";
Component: Mobile → Privacy: Anti-Tracking
Product: Web Compatibility → Core

The issue still occurs.

Tested with:
Browser / Version: Firefox Nightly 100.0a1 (🦎 100.0a1-20220322065927)
Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

status-firefox100: --- → affected
Assignee: nobody → wisniewskit

The bug assignee didn't login in Bugzilla in the last 7 months.
:timhuang, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: wisniewskit → nobody
Flags: needinfo?(tihuang)
Assignee: nobody → twisniewski
Flags: needinfo?(tihuang)
Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/774e38453f9d
Improve the styling applied to iframes injected by the SmartBlock shim for Google Publisher Tags to prevent conflicts with some websites; r=denschub,webcompat-reviewers

https://hg.mozilla.org/mozilla-central/rev/774e38453f9d

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox101: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch

The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(twisniewski)
status-firefox100: affected → wontfix
status-firefox99: affected → wontfix
Flags: needinfo?(twisniewski)
You need to log in before you can comment on or make changes to this bug.