Debugging an addon in Fenix Nightly

[DaveRo]

This thread is forked from here:

Add-on support in new Firefox for Android

Hey @DaveRo, try running the following in the browser console: ChromeUtils.import("resource://gre/modules/GeckoViewTab.jsm").GeckoViewTabBridge.openOptionsPage(<extension id>)

@caitlin Thanks.

The addon is one I referred to here: https://github.com/mozilla-mobile/fenix/issues/11308#issuecomment-662877387

I tried it:

ChromeUtils.import(“resource://gre/modules/GeckoViewTab.jsm”).GeckoViewTabBridge.openOptionsPage(“mudcat_browse_tools@davero.addons.mozilla.org”)

Uncaught
Exception { name: “NS_ERROR_FILE_NOT_FOUND”, message: “”, result: 2152857618, filename: “debugger eval code”, lineNumber: 1, columnNumber: 0, data: null, stack: “@debugger eval code:1:13\ngetEvalResult@resource://devtools/server/actors/webconsole/eval-with-debugger.js:231:24\nexports.evalWithDebugger@resource://devtools/server/actors/webconsole/eval-with-debugger.js:162:14\nevaluateJS@resource://devtools/server/actors/webconsole.js:1134:38\nevaluateJSAsync/<@resource://devtools/server/actors/webconsole.js:1028:29\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22\n”, location: XPCWrappedNative_NoHelper }
debugger eval code:1:13

Screenshot https://www.cjoint.com/data/JIxjZNUgPWZ_Fenix-debug-2020-09-23-10-49-37.png

I’m using the latest version of Fx on OpenSuSE, which is 78.2.0esr. Too old?

On the Fenix add-ons page, the temporary extension appears as ‘not yet available’. Could it be changed (in future) so that a temporary addon appears as installed, like ‘enabled’ addons, then I could presumably access the options via the settings tab?

[caitlin (Caitlin Neiman)]

Thanks @DaveRo; sorry that didn’t work out. Can you try instead to call browser.runtime.openOptionsPage() via the devtools of the extension/background page?

On the Fenix add-ons page, the temporary extension appears as ‘not yet available’. Could it be changed (in future) so that a temporary addon appears as installed, like ‘enabled’ addons, then I could presumably access the options via the settings tab?

I passed this along to the engineering team and they just landed a patch for it. You should see this in the next Nightly build.

[DaveRo]

Thanks. Inspecting my (or any) addon gives:
“Spec for webExtensionDescriptor specifies a ‘connect’ method that isn’t implemented…”
I think that indicates I need to update Firefox (to 83a? Will 82b do?) which I will. Meanwhile I changed the option defaults and it all works.

On the layout differences I mentioned in the other thread:
I’m inserting elements into a 1998-style webpage, laid out entirely using tables. (It’s how we used to do it before CSS!) I’m using absolute positioning, with the positions computed from the size and position of the existing elements - using Element.getBoundingClientRect() for example. And each element I add depends on the position and size of the last one. It’s horrible code, but it works.
Or it did. It comes out differently to Fennec. Not a problem, but interesting - especially since Chromium Edge makes the same ‘mistake’.
I’m beginning to suspect a timing issue: it renders faster on Fenix.
I mention all that just in case something rings a bell.

[juraj.masiar]

Ideally you should use Nightly Desktop to debug Nightly Firefox for Android. Or at least release version, not ESR.
The compatibility policy is to support 2 versions gap:

Is Android debugging still working?

Hi! Yes, remote debugging should still work fine If you are trying to debug Firefox for Android on your emulator, be aware that it is based on Firefox ESR (v68), so you need to connect to it from Firefox Desktop ESR68. You can download Firefox ESR at https://www.mozilla.org/en-US/firefox/all/#product-desktop-esr Our backward compatibility policy only supports a gap of 2 versions. This means that Firefox for Android (aka Fennec) can only be debugged from: Firefox 68, Firefox 6…

[DaveRo]

@juraj.masiar Thanks for the confirmation. I suppose the ESR version does not pick up any changes to the developer tools, so my ESR 78.2 is effectively the same as Release 78.0.

[freaktechnik (Martin Giger)]

It’s also possible that a spec was defined for the rendering edge case you’re hitting and it wasn’t implemented before Fennec got moved to the ESR branch. Two engines behaving the same indicates that interop work has happened.

[DaveRo]

It’s a good point. But this feature of the addon was released in May '18, long before Fennec 68. Still it could be due to some web compatibility change.

Just so you know what I’m describing, this is what these inserted elements (in green) look like in Fennec, and desktop Firefox. Also in Chromium and, I assume, Google’s Chrome - though I’ve never tested that: there are a few Chrome users and they’ve never complained.

On Fenix, and Chromium Edge, the buttons are displaced. I haven’t checked if the displacement is pixel-identical, but it’s similar.

Now I think that’s probably my bug. I suspect I’m making some assumption about the position of tables and textareas that was true in Firefox and Chromium, but isn’t in Fenix and Edge. I need to look into that.

The more interesting case is this third one, which (I think) happens when the reply box is on the end of a shorter thread. I suspect this is a timing issue.

Each button on the right, from top to bottom, uses the size of the one above it to line itself up. If I refresh, it does line up.

[juraj.masiar]

grid-template-areas

[DaveRo]

I’m familiar with CSS grids. If I end up rewriting the code then that might be a good way of lining up those green buttons: by putting them in a cell to the right of the textarea. I’d have to reliably identify all the elements that comprise the textarea, and the inputs below it, and place them in one cell, around which I would add my new cells.
But first I want to understand what’s going wrong - why the getBoundingClientRect() function is (sometimes) giving the wrong width for my just-inserted elements. I haven’t seen Edge do that - though I haven’t thoroughly tested it. But Edge is coming to Linux…

[juraj.masiar]

Well, I would advice you to avoid using javascript for style related issues .
If something can be solved with CSS, use CSS (I’m not sure if it applies to your problem as well).

Some positives of CSS:

• easy to define multiple styles for different screen sizes (media queries)
• easy to reason about, no magic, no race conditions, no variables, simple rules
• often much better performance (CSS engine is super fast)
• works even with disabled javascript

Anyway, from my own experience with getBoundingClientRect and layout related javascript issues, usually the problem is some race condition when your code runs before style engine recomputes layout. But sometimes things are just buggy .

EDIT:
Just to correct it a bit, there are no race conditions, there are a strict rules how javascript and rendering are executed. The point is that manipulating some layout related properties will not recalculate layout changes until the end of current event loop stack + microstack processing. More interesting info here:

[DaveRo]

@juraj.masiar

…from my own experience with getBoundingClientRect and layout related javascript issues, usually the problem is some race condition when your code runs before style engine recomputes layout

Perhaps that’s what’s happening here. I’d just not met the problem before. I’ll try slowing it down!