Debugging an addon in Fenix Nightly

This thread is forked from here:

@caitmuenster 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?

1 Like

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. :sunglasses:

1 Like

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.

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:

@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.

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.

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.

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…

Well, I would advice you to avoid using javascript for style related issues :slight_smile:.
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 :smiley:.

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:

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