1924334 - Neopets Explore page renders worse on Firefox Android than on Chrome Android

Status: UNCONFIRMED

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

Description

[Mateus Rodrigues Costa]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

Access https://www.neopets.com/explore.phtml

This page is responsive and contains a navigation bar (hamburger plus logo), a background that would be yellow with stars with a main section with white background and the main content and a footer with potentially an extra bar about login and sign up.

Actual results:

On Firefox Android The entire width of the page should adjust to the width of the device, instead it uses as much as it wants.
This makes the main section show up on the far left and a bunch of empty space with only the background stays to the right.

The extra space seems to be between 2 or 3 times the device width.
As an extra, the Signup/Login bar that should be at the very bottom is a bit higher than expected

Expected results:

Those issues don't happen on Chrome Android, meaning it's likely an issue with Firefox Android's handling of HTML and CSS.

Comment 1

[Mateus Rodrigues Costa]

Attachment: Neopets Explore page on Firefox Android 1

Comment 2

[Mateus Rodrigues Costa]

Attachment: Neopets Explore page on Firefox Android 2

Comment 3

[Mateus Rodrigues Costa]

Attachment: Neopets Explore page on Firefox Android 3

Comment 4

[Mateus Rodrigues Costa]

Attachment: Neopets Explore page on Chrome Android

Comment 5

[Mateus Rodrigues Costa]

The screenshots show the behavior on Firefox Android (with issues) and Chrome Android (working correctly)

Comment 6

[Mateus Rodrigues Costa]

So, I ran this on Firefox Desktop with the Responsive Design Developer tools and it also happens on Desktop =/

After some investigation turns this is the culpirit:

<span style="position: absolute; left: -1000px; top: -1000px; font-size: 300px; font-family: Carter One, sans-serif; font-variant: normal; font-style: normal; font-weight: normal; letter-spacing: 0px;">giItT1WQy@!-/#</span>

If I delete that element, everything works fine. On Chrome this element doesn't cause issues.

At worst I should be able to send a message to Neopets support asking for them to update the HTML from that page.
But, yeah, it's a Firefox bug shared between Firefox Desktop and Firefox Android that doesn't happen in Chrome Desktop nor Chrome Android.

Comment 7

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(In reply to Mateus Rodrigues Costa from comment #6)

So, I ran this on Firefox Desktop with the Responsive Design Developer tools and it also happens on Desktop =/

After some investigation turns this is the culpirit:

<span style="position: absolute; left: -1000px; top: -1000px; font-size: 300px; font-family: Carter One, sans-serif; font-variant: normal; font-style: normal; font-weight: normal; letter-spacing: 0px;">giItT1WQy@!-/#</span>

If I delete that element, everything works fine. On Chrome this element doesn't cause issues.

Good find! So they've got some extremely wide content that they try to position off the top-left corner of the page. That seems to prop up the width of the viewport -- this element is successfully off the top of the screen, but it still bleeds into (and across) the viewport's width, which is why it props up the viewport width. It's interesting that we've got a behavior-difference around that.

If you want to suggest a fix to the developers: Assuming they want to keep this magic tag, you could suggest any of the following:
(1) removing the font-size:300px there -- with that removal, the characters would be much smaller (small enough to not overshoot the left offset). That fixes the issue for me.
(2) increase the magnitude of their left declaration -- their current -1000px is not big enough to push the element fully off the left side of the viewport (it only takes ~3-4 300px-wide characters to overshoot the 1000px offset that they're using, and they've got many more characters than that here.) If I bump that up to e.g. left: -10000px (adding a 0), then that fixes the issue for me.

Comment 8

[Daniel Holbert [:dholbert] (PTO until 2/24)]

The Firefox/chrome behavior difference here is tracked in bug 1267004.

Comment 9

[Mateus Rodrigues Costa]

Hi, is this still being worked on?

Comment 10

[Daniel Holbert [:dholbert] (PTO until 2/24)]

We've identified the root cause of the behavior-difference (comment 8); nobody's actively working on that bug at the moment, but it's on a list of bugs with known site impact that we're working through.