Forecast is broken at metoffice.gov.uk with ETP set to STRICT
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: rbucata, Assigned: twisniewski)
References
(Blocks 1 open bug, )
Details
Attachments
(3 files)
Environment:
Operating system: Android 11/ Android 12
Firefox version: Firefox Nightly 102.0a1 (2015881419-🦎102.0a1-20220519093729🦎)
Preconditions:
ETP set to STRICT
Clean profile
Steps to reproduce:
- Navigate to: https://www.metoffice.gov.uk/weather/forecast/u12h6cbqp#?date=2022-05-21
- Accept the "Cookie Policy".
- Observe the result.
Expected Behavior:
The forecast is displayed as expected.
Actual Behavior:
The UI of the forecast is broken.
Notes:
- Not reproducible with ETP set to STANDARD.
- Works as expected using Chrome.
- Screenshot is attached.
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
I see this extra error in the console:
Uncaught TypeError: can't access property "getElementsByTagName", document.getElementById(...) is null
setTabIndex https://www.metoffice.gov.uk/webfiles/1650968389262/js/minified/advertising.min.js:14
fireSlotEvent https://securepubads.g.doubleclick.net/tag/js/gpt.js:35
fireSlotEvent https://securepubads.g.doubleclick.net/tag/js/gpt.js:32
fireSlotEvent https://securepubads.g.doubleclick.net/tag/js/gpt.js:31
callbackIfSlotReady https://securepubads.g.doubleclick.net/tag/js/gpt.js:70
refresh https://securepubads.g.doubleclick.net/tag/js/gpt.js:314
renderAdSlots https://www.metoffice.gov.uk/webfiles/1650968389262/js/minified/advertising.min.js:12
run https://securepubads.g.doubleclick.net/tag/js/gpt.js:399
<anonymous> https://securepubads.g.doubleclick.net/tag/js/gpt.js:412
advertising.min.js:14:232
So it seems that the page is expecting a certain DOM element to be on the page which our SmartBlock shim for Google Publisher Tags somehow isn't allowing to be created. This requires more diagnosis.
Assignee | ||
Comment 2•2 years ago
|
||
This is actually simpler than I'd feared. Basically the site is telling GPT there is a slot, but its element doesn't actually exist in certain responsive page-sizes. So we can just skip pretending the slot is ready in those cases (not trying to load the iframe in it, or firing the related slot events). Basically add this early-return case to callbackIsSlotReady
in our shim:
if (!document.getElementById(slot.getSlotElementId)) {
return;
}
Assignee | ||
Comment 3•2 years ago
|
||
Actually no, I erred in my testing. It appears that we will probably need to add logic to avoid or remove the slots which are not specific by the page to be needed on a given responsive page width/height. I'll look into that ASAP.
Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Pushed by twisniewski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/70ef6a243844 revamp the GPT SmartBlock shim to more correctly handle slot placement; r=ksenia,webcompat-reviewers
Comment 6•2 years ago
|
||
bugherder |
Comment 7•2 years ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.
Comment 8•2 years ago
|
||
The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox103
towontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•2 years ago
|
Comment 9•2 years ago
|
||
The issue is still reproducible, the layout is broken with ETP - Strict.
https://prnt.sc/yG2YSx7NEQvR
Tested with:
Browser / Version: Firefox Nightly 105.0a1 (🦎 105.0a1-20220816095503), Firefox Release 103.2.0 (🦎 103.0.2-20220802163236)
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)
Reopening this, Tom can you check it?
Comment 10•1 year ago
|
||
Assignee | ||
Comment 11•4 days ago
|
||
This just isn't reproducing for me right now, so I suspect this has since been fixed. If anyone can still reproduce this, please let us know.
Description
•