1901242 - Infinite redirection when opening Google Meet meeting room link if Side View is enabled

Status: RESOLVED MOVED

(WebExtensions :: Developer Outreach, defect, P2)

Description

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

I don't have any STR that works on a fresh profile, but internally we have a couple of people who experienced this, so filing bug to track the issue.

Comment 1

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

Surprisingly it turns out that disabling Side View fixes the issue. I have no idea how this extension can affect the non-sideview page...

Comment 2

[Sunil Mayya]

Thanks Kagami,
We would need some logs to proceed. I will keep this monitor queue until we have STR or have http logs.

Comment 3

[:Gijs (he/him)]

It looks like sideview has a bunch of logic that can replace UA headers in requests, cf. https://github.com/mozilla/side-view/blob/bda1db235f642917ae6a9d29877697108243a0bb/addon/background.js#L189-L204 .

Wil and pdehaan, you're listed as one of the committers - any chance you can help figure out what side view is doing here, and/or why? These are requests in the main pane (not inside side view) so I'm surprised the extension has any effect.

(Kagami: it would be interesting to just see network logs as well, per Sunil's comment.)

Comment 4

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

Okay, as we learned it's related to the extension now I got an STR too:

1. On a fresh profile, install Side View, and close the auto-opened side view
2. Open a Google Meet meeting room link (In a form of meet.google.com/(some-meet-id)). You don't have to sign in.
3. Allow firewall access if the prompt shows up
4. The page loads well at this point. Refresh the page.
5. Now it infinitely redirects.

And here's the profile: https://share.firefox.dev/4aTbVHj

Comment 5

[Wil Clouser [:clouserw]]

Side View was last maintained 6 years ago as an experiment within Test Pilot (which was ended). I'm surprised to see it still on AMO. I'm also surprised the repository hasn't been archived - I thought it had. All this to say, sorry, no, I don't know what's going on.

Comment 6

[:Gijs (he/him)]

OK. I've confirmed locally that the issue is that side view overwrites the user agent header for every non-toplevel-tab load.

It uses this request filter:

// This is a RequestFilter: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/RequestFilter
// It matches tabs that aren't attached to a normal location (like a sidebar)
// It only matches embedded iframes
let requestFilter = {
  tabId: -1,
  types: ["main_frame"],
  urls: ["http://*/*", "https://*/*"],
};

this ends up matching iframes in the meet.google.com page, for which it then overwrites the UA header with this now-ancient mobile user agent:

const USER_AGENT = `Mozilla/5.0 (Android 4.4; Mobile; rv:${FIREFOX_VERSION}) Gecko/${FIREFOX_VERSION} Firefox/${FIREFOX_VERSION}`;

I'm guessing the "Android 4.4" thing makes things sad at this point.

I'll ask around to figure out what our options are to fix this at this point.

Comment 7

[:Gijs (he/him)]

Necko can't fix this so moving this out of there.

At least one part here is going to require webextension API changes.

I'll keep the needinfo to see if just updating the UA string to be more modern and/or hacking around bug 1903789 would resolve the issue for now. Might be a few days for me to get to this.

Comment 8

[Greg Stoll :gstoll]

I think this is a closer component - External Software Affecting Firefox is more about DLL injection, etc.

Comment 9

[:Gijs (he/him)]

(In reply to Greg Stoll :gstoll from comment #8)

I think this is a closer component - External Software Affecting Firefox is more about DLL injection, etc.

but the WebExtensions product is for issues with our own webextension implementation inside the browser (ie the provision of APIs etc.). So that is also not right.

There used to be a "web compat" equivalent for add-ons, but I don't see that component anymore. At least by name, webextensions are external software - bugs in them cannot be fixed in Firefox itself.

Comment 10

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

I'm not sure what the root cause might be here, but the (unmaintained) side view repo has a duplicate bug, https://github.com/mozilla/side-view/issues/455

Comment 11

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Just FYI - I tried the most obvious and hacky fix, bumping the hard-coded Android version from 4.4 to 14 in the mobile-spoofing UA string, and it seems to fix Google Meet, so I landed the fix over on the github repo and tagged it as a new release. Next steps would seem to be getting the add-on signed and uploaded to AMO; I will mark those bugs as blocking this bug as I get them filed.

Comment 12

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

OK, I take that back--changing the UA string fix did not fix the bug. However, the side view addon has a hardcoded list of domains that are always loaded in desktop mode[1] ; adding the google meet URLs to that list[2] does seem to work around the bug.

[1] https://github.com/mozilla/side-view/blob/master/addon/background.js#L12
[2] https://github.com/mozilla/side-view/pull/460

Comment 13

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Note that the fix for the google meet bug is now live on AMO.