Open Bug 2004679 Opened 9 months ago Updated 4 months ago

paybill.com - Unsupported page displayed

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Platform:
Desktop
Windows 10
Type:
defect

Tracking

(Webcompat Priority:P3, Webcompat Score:2)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P3
Webcompat Score 2

People

(Reporter: ctanase, Assigned: twisniewski)

References

(Depends on 2 open bugs,
URL
)

Details

(5 keywords, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:blocked
configuration:general
affects:all
branch:release
diagnosis-team:webcompat
user-impact-score:20

Attachments

(2 files)

image.png
117.66 KB, image/png
Details
Bug 2004679 - add a UA override for paybill.com; r?denschub
48 bytes, text/x-phabricator-request
Details | Review

Environment:
Operating system: Windows 10
Firefox version: Firefox 147.0/145

Steps to reproduce:

  1. Go to https://paybill.com/occourts/
  2. Observe the page.

Expected Behavior:
Payments page displayed.

Actual Behavior:
Unsupported page displayed.

Notes:

  • Seems to work with Chrome Mask
  • 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/193684

Attached image image.png —

Chrome Mask ain't workin. Let's investigate properly.

Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 6
Depends on: firefox-not-supported
Keywords: webcompat:needs-contact, webcompat:needs-diagnosis, webcompat:needs-sitepatch
Priority: -- → P2
Webcompat Score: 6 → 5

It seems the ASP.NET backend does that on HTTP level:

GET /occourts/ HTTP/1.1
Accept: */*
Accept-Encoding: deflate, gzip
Host: paybill.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Edg/133.0.0.0

HTTP/1.1 200 OK
Cache-Control: private
Server: volt-adc

<!DOCTYPE html PUBLIC "-// …

for Edge UA above, whereas for Fx the response is:

GET /occourts/ HTTP/1.1
Accept: */*
Accept-Encoding: deflate, gzip
Host: paybill.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

HTTP/1.1 302 Found
Location: /occourts/UnsupportedBrowser.aspx
Server: volt-adc

<html><head><title>Object moved</title></head><body>

(and that page does not do any further sniffing — i.e. once that page is accessed, no UA changes redirect back, that's a dead end.)

The same is for Android UAs (Edge OK, Fx not), it also won't accept just any random bogus UAstring, but apparently allows ancient UAs, e.g.:

  • Opera/9.80 (S60; SymbOS; Opera Mobi/498; U; sv) Presto/2.4.18 Version/10.00
  • Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16.2
  • Opera/9.80 (Windows NT 6.1; U; fy-nl) Presto/2.7.62 Version/11.01
  • Mozilla/5.0 (Windows NT 5.1) Gecko/20100101 Firefox/14.0 Opera/12.0

(which leads me to thinking it might have issues with parsing v99 vs. v1xx version values, I'll try some more variants…)

So the trigger for evaluating as unsupported Internet Explorer from UA is the rv:* bit in platform, no matter what value.

  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv 1) Gecko/20100101 Firefox/123.0 [NB: space] works
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:1) Gecko/20100101 Firefox/123.0 [NB: colon] fails

That seems to stem from IE11 user agents:
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko
Mozilla/5.0 (compatible, MSIE 11, Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

where they seem to parse the tokens and at some point decide on the rv:* as being IE11 apparently?

Keywords: leave-open
Assignee: nobody → twisniewski
Status: NEW → ASSIGNED
User Story: (updated)
Webcompat Score: 5 → 1
Webcompat Priority: P2 → P3
Depends on: 2032198

(I spun off bug 2032198 as a platform-bug to cover our difference vs. other browsers here, identified in comment 4 -- thanks janbrasna!)

Keywords: webcompat:needs-diagnosis → webcompat:platform-bug

We had a similar issue (bug 1805967) where some websites blocked Firefox versions 110–119 because the websites' IE11 checks for rv:11 matched rv:110.0 in Firefox's UA string. We worked around that issue by hard coding rv:109.0 until Firefox 120.

I skimmed paybill.com's <script> files and found some references to navigator. and userAgent, but nothing that checks for rv. They're probably checking on the server side.

If we knew of more than one website broken by rv: or paybill.com is using a JS library that other websites might use, I would suggest we try removing it (in Daniel's bug 2032198). But with only one known broken website, I'm on the fence.

See Also: → 1805967
User Story: (updated)
Webcompat Score: 1 → 2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: