mako.co.il - Desktop version instead of mobile version received
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P2, firefox129 affected, firefox131 affected)
Webcompat Priority | P2 |
People
(Reporter: rbucata, Assigned: hiro)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(Keywords: webcompat:platform-bug, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])
User Story
platform:android impact:significant-visual configuration:general affects:all branch:release diagnosis-team:layout
Attachments
(2 files)
Environment:
Operating system: Android 13
Firefox version: Firefox 129.0
Steps to reproduce:
- Navigate to: https://mako.co.il
- Observe
Expected Behavior:
Mobile version is received
Actual Behavior:
Desktop version is received
Notes:
- 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/140604
Reporter | ||
Updated•6 months ago
|
I don't think it's the desktop side, but the mobile one. The problem is that the mobile website is broken, and the menu appears next to the main screen.
Updated•5 months ago
|
Comment 2•4 months ago
|
||
This looks like an APZ figuring-out-the-layout-viewport-when-some-content-is-offscreen-to-the-right sort of issue, similar to bug 1911457.
This reproduces in responsive design mode usually (might require a shift+reload).
Quick analysis: In the initial page rendering, they place the menu off the right side of the screen, and we think that means we should zoom out so that it's visible, but of course the site doesn't intend for that to happen.
Specifically:
- The body has
overflow:hidden
- The menu is absolutely positioned and shifted offscreen via
transform:translate
:
.Hamburger_sideMenu__bDy4P {
transform: translate(100%);
overflow: auto;
background-color: #303a51;
height: 100dvh;
width: 460px;
position: absolute;
top: 0;
right: 0;
If you tap the hamburger menu icon to open the menu, they add another rule that applies transform: translate(0);
to bring it onscreen, and the weird zoom-out effect goes away. But then when you close the menu, the original transform: translate(100%);
takes effect and shifts it offscreen again, and you get back to the initial broken rendering.
(Every now and then in Responsive Design Mode, things end up working as-intended (either initially or after I open/close the menu), but I'm not sure precisely why.)
hiro, do you have any insight into what's going on here and why this works out better in Chrome vs. Firefox?
Comment 3•4 months ago
|
||
(Per bug 1911457 comment 14, it sounds like we can group this under "viewport-compat" metabug and known categories-of-issues related to that, and maybe consider that the underlying platform bug, until/unless we get a reduced testcase here that can be spun off to a more-specific platform bug.)
Assignee | ||
Comment 4•3 months ago
|
||
The transform: translate(100%)
element Daniel found in comment 2 is underflowed in RTL contents, thus it should not affect the minimum-scale size. That's the problem.
That's being said, there may be another problem on the site, https://mako.co.il/ . I have a local patch to fix the underflow problem, with the patch, the site is correctly laid out initially, while being loaded the site at some point, it's rendered incorrectly, and then once after the site has been loaded, it's rendered correctly again.
Anyways, I am going to focus on the underflow problem here.
Assignee | ||
Comment 5•3 months ago
|
||
Updated•3 months ago
|
Backed out for causing reftest failures @ 1166147.html
- Backout link
- Push with failures
- Failure Log
- Failure line:
REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/pagination/1166147.html == layout/reftests/pagination/1166147-ref.html | image comparison, max difference: 10, number of differing pixels: 1452
Assignee | ||
Comment 8•3 months ago
|
||
Thanks to the test case, found a silly mistake that we need to use BStart
but I did use BEnd
there.
Comment 10•3 months ago
•
|
||
Backed out for causing reftests failures in 1133905-1-vh-rtl.html.
- Backout link
- Push with failures
- Failure Log
- Failure line: REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/bugs/1133905-1-vh-rtl.html == layout/reftests/bugs/1133905-ref-vh-rtl.html | image comparison, max difference: 54, number of differing pixels: 320
Please also check these reftests failures.
Failure log
Assignee | ||
Comment 11•3 months ago
|
||
The incorrect rendering is the reference one, 1133905-ref-vh-rtl.html. It has <meta name="viewport" content="initial-scale=1.0">
so that even though the correct minimum-scale of the document is less than 1.0, the content gets rendered as 1.0 zoom scale.
Without the change for this bug, the minimum-scale is incorrectly calculated as 1.0, thus we have never seen bug 1931482.
With the change for this bug, the minimum-scale is correctly calculated, thus we see bug 1931482.
Anyways, I am going to leave this bug open, since I have no idea how to fix bug 1931482, it would take more time.
Updated•21 days ago
|
Description
•