Ungoogled-chromium: Can't inspect remote devices if the remote device's version of Chromium is older than ungoogled-chromium

[nikolowry]

Describe the bug
chrome://inspect/#devices no longer is working when ungoogled-chromium is newer than the remote Chromium browser being inspected. However, when the remote Chromium browser is newer than ungoogled-chromium, chrome://inspect/#devices will display a new option inspect-fallback which does work. I suspect this related to bundling the local devtools and domain substitutions.

To Reproduce
Steps to reproduce the behavior:

1. Go to chrome://inspect/#devices while a remote device running an older version of Chromium and is connected via ADB
2. Click on inspect
3. See devtools error, screenshot below

Expected behavior
To inspect remote tabs via devtools

Screenshots

Environment (please complete the following information):

• Archlinux
• Ungoogled-chromium v81.0.4044.113

Additional Context
I haven't had matching Android/ungoogled-chromium version clients in month -- do not know what happens when versions match.

Potential fix
There's an "easy" fix for this, which is to always enable inspect-fallback by creating a patch that changes https://github.com/chromium/chromium/blob/81.0.4044.113/chrome/browser/resources/inspect/inspect.js#L337-L338 to:

const browserNeedsFallback = true;

I've validated locally that force-enabling inspect-fallback allows remote debugging regardless of the Chromium version running on the remote device. Here's a screenshot of it working:

Should we also change the message printed below the remote device version from "Remote browser is newer than client browser. Try 'inspect fallback' if inspection fails" to just "Try 'inspect fallback' if inspection fails"?

Didn't want to open a PR before proposing it in this ticket, please advise on the next steps which I should take. Should this be a standalone patch or should it be added to https://github.com/Eloston/ungoogled-chromium/blob/master/patches/core/ungoogled-chromium/use-local-devtools-files.patch?

[PF4Public]

Connecting to older version works for me on Gentoo (Version 81.0.4044.122):

[nikolowry]

I'm going to feel silly if this is just a case of "doesn't work on my machine". I'll look a little deeper into why my inspect command is returning "404 not found".

Additional context on my remote device:

• Chromium with Bromite browser's patchset
• LineageOS 16.0 w MicroG

[PF4Public]

Just FYI I tried to connect to old Chrome (not -mium, not ungoogled).

[nikolowry]

@PF4Public I can confirm that Google's Chrome builds are not affected by this issue. Inspecting the remote device on a version of Chrome older than ungoogled-chromium is working as expected.

This has only been happening very recently (~v80), so I'm thinking it might be related to Google's recent push of using "Dynamic Feature Modules" on Android and Bromite's patch set.

[PF4Public]

Could those builds be lacking some inspector resources?

[nikolowry]

@PF4Public I'd need to dig deeper into the relevant Bromite patches and Android-specific build files to pinpoint the root cause. If I had to guess though, it'd be that the inspector resources were marked as "non-critical" in Android builds and are no longer being bundled into local builds by default.

Regardless, I don't think it's such a bad idea to have inspect-fallback permanently force-enabled so any edge-case like this will always have a viable workaround.

@csagan5 any thoughts or ideas?

[csagan5]

@nikolowry see my reply on https://github.com/bromite/bromite/issues/526

Could those builds be lacking some inspector resources?

The URL devtools://devtools/remote/serve_rev/@4738de409d42eeb4071c354860aae28c8ab13ce6/inspector.html?remoteVersion=81.0.4044.106 is accessible and causes a remote load, so I cannot really understand where the 404 comes from.

@nikolowry perhaps starting the browser with --auto-open-devtools-for-tabs will allow to debug the source of this 404?

[nikolowry]

@csagan5 appreciate the context! I just ran ungoogled-chromium from the command line, tried inspect and got this output:

[383105:383115:0428/183848.244280:ERROR:trk_protocol_handler.cc(17)] Blocked URL in TrkProtocolHandler: trk:https://chrome-devtools-frontend.8pp2p8t.qjz9zk/serve_rev/@2fbd5366be4fc4343c9e7abe6eaea617ac15b199/inspector.html?remoteVersion=81.0.4044.127&remoteFrontend=true&dockSide=undocked&experiments=true

So at the very least we know devtools://devtools/remote is just an alias for https://chrome-devtools-frontend.appspot.com/. I'll be working on this whenever I have spare time over the next few days. I'll report back here once I have something worthwhile to share

[csagan5]

The problem is probably here: https://github.com/Eloston/ungoogled-chromium/blob/c2a89fb/domain_substitution.list#L17

I will fix this in Bromite since in https://github.com/bromite/bromite/issues/526 there is no ungoogled-chromium/Bromite involved on the local side.

ungoogled-chromium does not need to fix this because it uses bundled dev tools; it is however not that easy to do the same in Bromite because the changes are in a sub-repo.