steps to reproduce/what did you do?

• Menu > More Tools > Customize toolbar
• Move the "Take Screenshot" button next to the address bar.
• Go on another page.
• Attempt to click on the "Take Screenshot" button.

expected behavior/ what did you think will happen?

• The "Take Screenshot" button is white. (over dark background)
• Display a popup/drop-down to select elements in the page.

actual behavior/ what actually happened?

• The button is gray instead of white for every page. (over dark background)
• Nothing happens

Note: The context menu (right click on a page) has a "Take Screenshot" entry, but it does not display anything either.

I can't reproduce, FWIW (using latest Nightly on Linux).

Specifically: the screenshot button (if I drag it to the toolbar) looks enabled for me, and it does activate the "take-a-screenshot" page-overlay UI when I click it. Also, the context-menu item works for me as well.

Which page were you trying to screenshot? Note that screenshots are disabled for privileged pages like about:config and about:preferences (for technical reasons, I think; ideally they would be screenshottable). Were you perhaps trying to screenshot one of those pages, and do you see the same issue at https://www.example.org/ ?

(screenshots are disabled on the new-tab page as well, i.e. about:home)

I have this on all pages. As you can see on this screenshot showing this bug. The icon is non-clickable.

Very odd! I wonder why I'm not seeing that behavior on my end. Could you see if this is reproducible in a fresh profile on your machine?

Also, what OS are you testing on? (I've tested Linux & Mac, and can't reproduce in either.)

I am running on NixOS.
Testing on a fresh profile seems to work fine.

Looking at about:config, I found the following in extensions.webextensions.uuids:
Old profile: dbae84ef-fbb3-4ec1-b56e-5cc10c5e43f9
New profile: 32376363-01f3-4a04-bcb4-8cce7378b79d

I do not know if I have any mean to force the update these web extensions.

FWIW: in my regular browsing profile, my screenshots webextesion UUID is acfa0a79-7f9d-3c49-b2be-4290a0ade71a, which doesn't match either of the UUIDs you mentioned. (I have no idea how version-specific and/or unique that uuid is meant to be.)

I also noticed that I can find the location of the webextension XPI-file itself by visiting moz-extension://[uuid], i.e. moz-extension://acfa0a79-7f9d-3c49-b2be-4290a0ade71a in my case. That gives me a listing that has this as the first line:

jar:file:///Applications/Firefox%20Nightly.app/Contents/Resources/browser/features/screenshots@mozilla.org.xpi!/

Note that this is in the browser installation itself (it's not profile-specific).

In your case, since you're getting two different UUIDs, I wonder if one of them is using an .xpi (maybe a stale one) that happens to live in your profile directory?

(In reply to Daniel Holbert [:dholbert] from comment #7)

I also noticed that I can find the location of the webextension XPI-file itself by visiting moz-extension://[uuid], i.e. moz-extension://acfa0a79-7f9d-3c49-b2be-4290a0ade71a in my case. That gives me a listing that has this as the first line:

jar:file:///Applications/Firefox%20Nightly.app/Contents/Resources/browser/features/screenshots@mozilla.org.xpi!/

Note that this is in the browser installation itself (it's not profile-specific).

This would be the issue!

NixOS install programs in new directory each time, based on the hash of recipe used to build the program. So nightly version N is stored in a different directory than version N+1. (same is true for releases)

Thus, Firefox binaries which are executed are never found at the same location, and if older version are garbage collected, the jar file is no longer found. Security wise, this sounds like a bad design to hard-code the path of the version used to create the profile.

I guess this is something which might be reproduced on other systems by installing the same version on 2 different paths, then creating a profile with the version installed in one path. Removing this path, and starting the same profile with the other path.

Tested in the new profile, deleting extensions.webextensions.uuids updates the screenshot web-extension uuid to the new installation directory (?!), which does not match the new installation directory, and cause a new issue where the icon is not gray, but the screenshot button does not work.

Testing the following procedure:

• Install ESR
• Create a new profile P with ESR
• Install Release
• Start P with Release — Addon path is correctly updated.
• Install Beta
• Start P with Beta — Addon path is correctly updated.
• Install Nightly
• Start P with Nightly — Addon path is correctly updated.

I will have to test with multiple versions within the same channel on beta / release to see if this problem exists, but it seems that the problem does not exists when moving to a newer version of Firefox, and that the path referenced is correctly updated.

The extension uuids are assigned when the extension is installed, and so that uuid is expected to different for the same extension installed in two different profiles.

About the path to the extension xpi file:

the path to the screenshot addons xpi file is not hardcoded, but when the extensions are installed we are storing the absolute path to their xpi files in the startup cache (there are performance reasons for that, e.g. to avoid doing expensive filesystem-related calls during the browser startup, like listing the xpi files in the addon install locations) for all extensions.

See Bug 1429838 for what should be a similar issue (but for the scenario where it is the Firefox profile dir to have been moved in a different path, which does have a similar effect but for the extension installed in the profile location, instead of a system addon installed from an app location).

About the behavior described in comment 10:

• Firefox does a complete scan of all the addon install location when a profile is being started with a Firefox release that is different from the one that was used on the particular profile in a previous run

If I recall correctly we should also do the same for Nightly builds that have a different buildId (see this code from the XPIProvider.jsm) and so I'm wondering if in the two different nix builds of Nightly did have a different nix store path (e.g. because of changes to some other inputs of that nix derivation) but sharing the same buildId.

Hi Nicolas B. Pierron,
would you mind to verify the build id for the two different Firefox nightly nix builds to confirm if that was the case?
(it should be enough to call Services.appinfo.appBuildID in the Browser Console on the two Nightly instances that are triggering the issue for you).

Testing procedure:

• Create & Run profile P with /nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1 :
  • jar:file:///nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1/usr/lib/firefox-bin-89.0a1/browser/features/screenshots@mozilla.org.xpi!/
  • build-id = 20210412213434
• Run profile P with /nix/store/2a46695xdayzs4jvy04qmz2yajkf0bc0-firefox-release-bin-unwrapped-89.0a1 :
  • jar:file:///nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1/usr/lib/firefox-bin-89.0a1/browser/features/screenshots@mozilla.org.xpi!/
  • build-id = 20210414093129

(Note: I took the build-id from about:telemetry as I do not know how to type in the browser console)

(In reply to Nicolas B. Pierron [:nbp] from comment #12)

Testing procedure:

• Create & Run profile P with /nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1 :
  • jar:file:///nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1/usr/lib/firefox-bin-89.0a1/browser/features/screenshots@mozilla.org.xpi!/
  • build-id = 20210412213434
• Run profile P with /nix/store/2a46695xdayzs4jvy04qmz2yajkf0bc0-firefox-release-bin-unwrapped-89.0a1 :
  • jar:file:///nix/store/qjv05gqri1wld1j5l65y11j2dqg70hhm-firefox-release-bin-unwrapped-89.0a1/usr/lib/firefox-bin-89.0a1/browser/features/screenshots@mozilla.org.xpi!/
  • build-id = 20210414093129

(Note: I took the build-id from about:telemetry as I do not know how to type in the browser console)

thanks! (and yes taking it from about:telemetry was definitely ok, I forgot that we did have it more directly visible elsewhere, besides about:telemetry it is also in about:support)

It looks that we should have been doing a full scan based on the two build-ids, and so it is surprising.

I'm going to set a needinfo assigned to me to reproduce it locally

(I think I should be able to reproduce it without using the nix packages, by just using two of our nightly builds from two different paths on the same profile, but in the worst case I do use nix on my ubuntu dev machine and I'll give a try to reproducing it with the nix package, which I guess are coming from this repository: https://github.com/mozilla/nixpkgs-mozilla)

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #11)

If I recall correctly we should also do the same for Nightly builds that have a different buildId (see this code from the XPIProvider.jsm) and so I'm wondering if in the two different nix builds of Nightly did have a different nix store path (e.g. because of changes to some other inputs of that nix derivation) but sharing the same buildId.

This is definitely possible as the dependencies might be updated without a Firefox update, but this would be a NixOS issue. This does not seems to be the case here, as we get different build-ids.

I did investigate this issue a bit more today and it looks that I'm able to trigger a similar issue if I do something like:

• install firefox nightly into a "path A"
• create a new profile with the nightly installed in "path A"
• then remove the nightly from "path A" and install a new nightly in "path B" (or just move the existing installation from "path A" to "path B")
• use the same profile previously used from the "path A" instance with the "path B" one

For me this was failing consistently to load successfully any built in extensions if the buildid was the same one (it was trying to load them from path A and failing because those file didn't exist anymore), but it wasn't failing if the buildid was different (which should have been because of the full scan I did mention in one of my previous comments).

When the instance was failing to load the extension because missing, in the Browser Console there were errors like:

Unable to load script: jar:file:///nix/store/h0rsxaq5yw5v989bay84lrxv98ksivav-firefox-release-bin-unwrapped-89.0a1/usr/lib/firefox-bin-89.0a1/browser/features/formautofill@mozilla.org.xpi!/api.js Extension.jsm:2636
    startup resource://gre/modules/Extension.jsm:2636
    AsyncFunctionThrow self-hosted:699

I did also tried to test a similar scenario using mozregression, running something like:

mozregression -g 20210412213434 -b 20210414093129 --profile-persistence reuse

Then on the first instance downloaded and executed (20210412213434) I was running the following STR:

• enter customize, move screenshot button in toolbar, load wikipedia and trigger screenshot UI
• choose retry in mozregression console input
• load wikipedia, click screenshot button => nothing happens
• Browser console logs:

1618462204414	addons.xpi	WARN	Exception running bootstrap method startup on screenshots@mozilla.org: Error: Error while loading 'jar:file:///tmp/tmpwmkfk8a6/firefox/browser/features/screenshots@mozilla.org.xpi!/manifest.json' (NS_ERROR_FILE_NOT_FOUND)(resource://gre/modules/Extension.jsm:600:20) JS Stack trace: readJSON/</<@Extension.jsm:600:20
onStopRequest@NetUtil.jsm:128:18

But if instead of choosing retry I then choose good to let mozregression to download and run the other version (20210414093129), screenshot was loaded again (due to the different buildid).

At the moment this still doesn't look like a new issue (none of this should have been changed in the last few releases), and so we may evaluate to move this issue into "Toolkit::Add-ons Manager" bugzilla component for further investigationg but not consider it a new blocking issue for this particular release.

I still want to investigate it further, especially given that I couldn't reproduce it without actually making sure that the built in addons from the old install path were removed and the build id was the same, which it doesn't seem to exactly match the conditions described by Nicolas.

Hey Nicolas, would you mind to take a look to the Browser Console when you are able to reproduce the issue as you are experiencing it in your system? (and add the logs, especially if errors and suspiciously related to addons or screenshot, in a new comment or attachment on this bug)

I would like to see if there is anything in the Browser Console that could help me figure it out if I'm actually reproducing a similar enough scenario.

(As an additional side note, for me the screenshot toolbar button was enabled on the pages where it was supposed to be enabled even when screenshot addon was not actually loaded because missing).

Comment 16 was meant to be a needinfo.

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #16)

Hey Nicolas, would you mind to take a look to the Browser Console when you are able to reproduce the issue as you are experiencing it in your system? (and add the logs, especially if errors and suspiciously related to addons or screenshot, in a new comment or attachment on this bug)

Looking at my day-to-day profile, the issue seems to have gone away after a forced reboot. (and some removal of the screenshot line from extensions.webextensions.uuids)

Using the technique to reproduce the issue with different build id, I can reproduce the miss-naming location, when the path is removed. This yield the same error message as you mention in comment 15 (startup resource://gre/modules/Extension.jsm:2636) Otherwise it might still works.

I noticed that the fact of removing the path does not gray-out the icon (as in comment 3), and that the moz-extension://<uuid> show Access to the file was denied which I do not recall from my main profile. I suspect that the issue I noticed in my main profile might be an API incompatibility causing even more issues on top of the lack of update.

I do not know if this matters, but the Firefox installs of Nightly provided in nixpkgs-mozilla have a policy file which specify to not look for updates, as Firefox would download bits for nothing. Maybe this policy file inhibit the addon update within the same channel.

(In reply to Nicolas B. Pierron [:nbp] from comment #18)

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #16)

Hey Nicolas, would you mind to take a look to the Browser Console when you are able to reproduce the issue as you are experiencing it in your system? (and add the logs, especially if errors and suspiciously related to addons or screenshot, in a new comment or attachment on this bug)

Looking at my day-to-day profile, the issue seems to have gone away after a forced reboot. (and some removal of the screenshot line from extensions.webextensions.uuids)

Not for long apparently.
I just got this new error on my main profile, after the forced removal of the old Firefox nightly version:

uncaught exception: Unable to load script: moz-extension://3c68539c-d468-492c-bb1e-bed6a0f27a0c/build/buildSettings.js
[object Object] ExtensionCommon.jsm:747
    normalizeError resource://gre/modules/ExtensionCommon.jsm:747
    recvAPICall resource://gre/modules/ExtensionParent.jsm:950

edit:
As well a desktop notification https://searchfox.org/mozilla-central/source/browser/locales/en-US/browser/screenshots.ftl#48-49

Minor tangent that's worth noting here: based on a slack conversation with :nbp, we're pretty sure this whole issue is entirely unrelated to proton. I think it got lumped in with some proton annotations because it was filed under the foxfooding component during the proton-foxfooding period, but it's not a proton-specific thing.

(nbp, please correct me if I'm wrong)

So I don't think there's any need to track this as part of the proton frontend work.

(In reply to Daniel Holbert [:dholbert] from comment #20)

Minor tangent that's worth noting here: based on a slack conversation with :nbp, we're pretty sure this whole issue is entirely unrelated to proton. I think it got lumped in with some proton annotations because it was filed under the foxfooding component during the proton-foxfooding period, but it's not a proton-specific thing.

(nbp, please correct me if I'm wrong)

So I don't think there's any need to track this as part of the proton frontend work.

I do agree also from a WebExtensions / Add-ons Manager perspective (as I did mention at the end of comment 15).

If no one here disagree, I would move this into "Toolkit :: Add-ons Manager" and clear out Proton-related tracking, our team will investigate it outside of the foxfooding bug list as a general "Add-ons Manager & system addons issue" happening under certain corner cases.

Daniel, Feel free to move it in our component (or needinfo me and I'll be happy to move and update it accordingly)

Restarting my main profile with the same build-id:

The moz-regression://<uuid> shows a blank page.
A click on the button does not add any additional browser console messages at the moment of the click.

Filtering the browser console on extensions reports a few messages similar to:

can't access property "length", details.responseHeaders is undefined 19 heuristicblocking.js:542
    startListeners moz-extension://a505f06f-2fab-4990-8d7c-82b8fa997ea3/js/heuristicblocking.js:542
    apply self-hosted:2735
    applySafeWithoutClone resource://gre/modules/ExtensionCommon.jsm:621
    fire resource://gre/modules/ExtensionChild.jsm:806
    recvRunListener resource://gre/modules/ExtensionChild.jsm:810
    recvRunListener self-hosted:1178
    _recv resource://gre/modules/ConduitsChild.jsm:78
    receiveMessage resource://gre/modules/ConduitsChild.jsm:184
    run resource://gre/modules/ConduitsChild.jsm:175
    receiveMessage resource://gre/modules/ConduitsChild.jsm:176
    map self-hosted:224
    receiveMessage resource://gre/modules/ConduitsChild.jsm:176

I am not sure if this is related.

(In reply to Daniel Holbert [:dholbert] from comment #20)

Minor tangent that's worth noting here: based on a slack conversation with :nbp, we're pretty sure this whole issue is entirely unrelated to proton. I think it got lumped in with some proton annotations because it was filed under the foxfooding component during the proton-foxfooding period, but it's not a proton-specific thing.

I am no expert but I agree, as well as with Luca's comment 15, that this sounds like an old issue, and proton is only coincidental.

It looks that the three of us all agree that this looks unrelated to Proton, do you want to clear the Proton / foxfooding tracking field before I move this into "Toolkit :: Add-ons Manager"?

Sure, let's remove them (I'll update component while I'm at it).

(julien, looks like you added the Jira link - I'll leave it to you to close out and/or unlink that Jira ticket in whatever way makes sense, given that this is unrelated to Proton and seems to just be a regular longstanding bug.)

Ty - I closed the corresponding JIRA.

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Marking as a duplicate of Bug 1429838, which is tracking the underlying issue triggered by having the absolute path to the extensions in extensions.json, this issue is basically triggered by that but affecting builtin addons when is the application directory to have been moved to a different path.