Inconsistency between web-ext run and installation in profile

[benbasson]

Is this a feature request or a bug?

Bug (?) or at very least unexplained behaviour...

What is the current behavior?

I've been rewriting my add-on New Tab Homepage, source available:
https://github.com/benbasson/newtabhomepage/

It's a pretty basic add-on. All it does is load your homepage when a new tab opens.

When I "web-ext run" my add-on, it is able to inject some script ("window.focus()") into the newly updated tab. This passes focus to the loaded homepage, e.g. if the homepage is Google, you end up with focus on the page, and therefore the Google Search box rather than in the URL bar.

Now that I've published and installed my add-on, I notice that the focus behaviour doesn't work. I've tried to figure out differences between a "real" profile and a temporary profile used in "web-ext run", but I can't spot anything.

The script injection (presumably) fails, and the resulting error given is:

Cannot send function call result: other side closed connection (call data: ({path:"tabs.executeScript", args:[null, {allFrames:null, code:"window.focus();", cssOrigin:null, file:null, frameId:null, matchAboutBlank:null, runAt:"document_idle"}]}))

and

Ignoring response to aborted listener for 27-0

I am fully prepared and willing to accept that I'm doing something wrong here, but I can't explain away the inconsistency. I would expect it to always fail, rather than only fail on a real profile.

Steps to reproduce

1. Grab the source files for my add-on (it's 3 files) from https://github.com/benbasson/newtabhomepage/tree/master/src
2. web-ext run --pref browser.startup.homepage=google.com
3. Open new tabs
   -> focus should be in Google search box, not URL bar (which is what I want to happen)

Now try this by installing New Tab Homepage add-on from AMO into a clean Firefox profile
https://addons.mozilla.org/en-GB/firefox/addon/new-tab-homepage/

1. Create new Firefox profile
2. Install add-on from above link
3. Set homepage to "google.com"
4. Open new tabs
   -> cursor will be in URL bar at start of URL (e.g. prior to "https")
   -> error as described above will appear in the browser console

What is the expected or desired behavior?

Either it fails always in Firefox when installed to a standard user profile, and it fails always on "web-ext run", or works in both scenarios.

Version information (for bug reports)

• Firefox version: 57.0b10 (64-bit)
• Your OS and version: Windows 7 SP1 (64-bit)
• Paste the output of these commands:

node --version && npm --version && web-ext --version

v6.7.0
3.10.3
2.2.2

[kumar303]

Do you still experience the web-ext behavior if you go to about:debugging and manually load it as a temporary add-on?

[benbasson]

Nope.

Incidentally, if it wasn't clear, the web-ext behaviour is what I want to happen, but either creating a new Firefox profile and installing the add-on, or using about:debugging exhibits the "wrong" behaviour.

The issue I have is that probably I'm doing something bad/wrong in my add-on code, and it's working how I want in web-ext, but not elsewhere. I also don't know what that mistake is, but I'm hoping that if the difference between web-ext and not-web-ext is discovered, it might shed some light.

[andymckay]

My guess is that like issue #970, the preferences that web-ext sets in the new profile are different. I'm betting its this line: https://github.com/saadtazi/firefox-profile-js/blob/b5821e92f7614c6f8ff6a4a0c93ff5264990ddb3/lib/firefox_profile.js#L43

[benbasson]

Unless I'm mistaken, that line is for first run, e.g. when you open Firefox for the first time? I'm not using that value,

I'm reading the actual homepage URL and then injecting that into a newly opened tab. My issue is that the focus call isn't working (outside of web-ext) due to the above error. The correct URL is, however, loaded in the tab.

I tried setting that pref to about:blank in my main profile anyway on the off chance, but it didn't make any difference.

[benbasson]

You were on the right track Andy, it's related to dom.disable_open_during_load. In the file above, it's set to false, but default is true.

[benbasson]

Curiously, I still get the callback error reported (maybe that's actually a red herring and not really a problem).

[benbasson]

Ok, can confirm

web-ext run --pref browser.startup.homepage=google.com --pref dom.disable_open_during_load=true

allows me to reproduce the problem reliably, as per a standard profile install.

[benbasson]

From my research, it looks like dom.disable_open_during_load is related to popup blocking, so I can imagine why this prevents me from doing things like programatically setting focus.

Filed a bug to request an alternative way of achieving my goal: https://bugzilla.mozilla.org/show_bug.cgi?id=1411465

I think this issue (the inconsistency with normal Firefox behaviour) still stands? If it's not desirable to fix (for whatever reason the preference was set this way) then perhaps this could be made clearer in the documentation for web-ext run?

[kumar303]

A few issues like this have popped up so maybe it would be helpful to add a web-ext option like --minimal-pref-changes that only open up the debugging port that web-ext needs and nothing else. It wouldn't be the greatest experience (auto-updating would be on and other annoying things) but it could be good for debugging.

[benbasson]

I don't know if a new type of profile is really necessary, but it seems odd to load a profile that has a load of tweaks that (seemingly) aren't relevant to debugging / add-on development, especially if they result in actual Firefox behavioural differences.

[kumar303]

it seems odd to load a profile that has a load of tweaks

This was intended to support two cases:

1. Make web-ext features work -- e.g. extension installation and automatic reloading
2. Set up Firefox for the use case of development -- e.g. turn off software updates, hide the usual first-run screen, etc

Maybe we could add an option to turn off the second case. We can't turn off the first case though because web-ext needs to work.

[benbasson]

Well, the only reason I raised this issue in the first place was because of a difficult-to-explain behavioural difference. I don't think there's a problem turning off software update or turning on debug features.