1738876 - tools.usps.com/rcas.htm is intermittently stuck in a loading state

Status: NEW

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

Description

[Raul Bucata]

Attachment: Screenshot_13.png

Environment:
Operating system: Windows 10 x64 PRO
Firefox version: :Firefox Nightly 96.0a1 (2021-11-01) (64-bit)

Preconditions:
ETP set to STANDARD
Clean profile

Steps to reproduce:

1. Navigate to :https://tools.usps.com/rcas.htm
2. Observe the result

Expected Behavior:
The page loads

Actual Behavior:
The page is stuck in a loading state

Notes:

• Not reproducible with ETP turned off
• Works as expected using Chrome
• Screenshot attached

Comment 1

[Tim Huang[:timhuang]]

This is also reproducible with CookieBehavior 4(ETP).

Comment 2

[Tim Huang[:timhuang]]

Hmm, the issue is still present if I disable ETP by using the ETP toggle.

Raul, could you verify again?

Comment 3

[Raul Bucata]

With a clean fresh profile, disabling the ETP by using the ETP toggle triggers the loading of the page on my side, as expected.

Tested with:

Browser / Version: Firefox Nightly 96.0a1 (2021-11-04) (64-bit)
Operating System: Windows 10 PRO x64

Comment 4

[Tim Huang[:timhuang]]

This is not constantly reproducible and I can reproduce it even with ETP disabled(Note that it might work on the first try, but you will see the issue after several refreshes). So, I think it's not an anti-tracking issue but more like a webcompat issue. Given this, I will lower the severity here and ni Tom for webcompat.

Comment 5

[Dennis Schubert [:denschub]]

I couldn't really test this because I haven't received an UPS shipment in the last 6 months. However, I found someone on LinkedIn who claims to work on WebDev stuff there, so I sent them a message. I'll update this bug if I hear back from them. :)

Comment 6

[James Graham [:jgraham]]

It seems like when this is broken we're getting an error Uncaught ReferenceError: unavailableTimer is not defined. unavailableTimer should get defined in a jQuery $(document).ready() call in schedule-jquery.js, which should run on DOMContentLoaded, whereas it should be used in $(window).on('load') in the same script. The script is a normal parser-blocking script, so there's no delayed script loading that causes the race.

However it seems that for some reason the $(document).ready call is happening in a setTimeout set after DOMContentLoaded, which I guess is racing with the load event. So we need to check if that also happens in Chrome and there's some slight timing difference or if they aren't running the setTimeout at all.

Comment 7

[Sean Feng [:sefeng211]]

Yeah, when DOMContentLoaded is fired, jquery will use setTimeout to schedule the call back for its $(document).ready() (start from here and the callback is scheduled at https://github.com/jquery/jquery/blob/3cad5c435aa2333c39baa55a8bceb2b6bf1e2721/src/deferred.js#L224). So In Gecko, there's a chance that the callback for $(window).on('load') gets to run first, hence unavailableTimer is undefined.

I used Chrome's debugger and confirmed that the callstack is the same. They also execute this window.setTimeout to schedule the callback.

Comment 8

[Sean Feng [:sefeng211]]

Attachment: demonstrate_behaviour.html

Attached a simple test case to demonstrate the behaviour.

Basically it'll keep reloading itself until the setTimeout callback is fired after the load event handler.

In Firefox, it'll keep reloading a couple of times and stops.

The weird thing is that I always get the same result such that the setTimeout callback is fired after the load event handler in Chrome. So they should hit the same issue as us, but they don't.........so something is working differently.

Comment 9

[Sean Feng [:sefeng211]]

Looking at this once again, I think my assessment in comment 7 is correct. They site relies on undefined behaviours. There's no guarantee $(document).ready() will always run before window.on('load').

My testcase also demonstrates this can be flaky in Chrome because, my testcase always gets window.on('load') runs first before $(document).ready(), whereas on this site, $(document).ready() always runs before window.on('load').

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Randal, it seems like this is a good candidate for turning off timer deferring.

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

*.usps.com is already opted out from timer deferral

Comment 12

[Jeff Muizelaar [:jrmuizel]]

I'm going to try outreach

Comment 13

[Hsin-Yi Tsai (she/her)[:hsinyi]]

As chatted in the webcompat channel, I am moving the keyword from webcompat:site-wait to webcompat:contact-in-progress.
The original *:site-wait keyword was added a year ago; this may be closer to webcompat:blocked ...

Comment 14

[Jeff Muizelaar [:jrmuizel]]

My outreach attempt failed.

Comment 15

[Dennis Schubert [:denschub]]

I'll give it a try via LinkedIn.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

Raul, can you still reproduce this? I'm not be able to.

Comment 17

[Kagami Rosylight [:saschanaz] (they/them)]

Err, never mind, I just got one.

Comment 18

[Kagami Rosylight [:saschanaz] (they/them)]

The trick is that:

1. From comment #0, Control+Click the link. Do not switch to the tab until it loads
2. Switch to the tab

High chance that the page is stuck. Maybe we somehow throttle setTimeout on background tab or something?