GeezerVison is showing github.com — Script doesn't run when using `firefox.exe <url>` · Issue #3117 · greasemonkey/greasemonkey
Script doesn't run when using firefox.exe <url> #3117DescriptionHi,
With this simple script :
// ==UserScript==
// @name Anonyme Script 387564
// @match https://www.dokuwiki.org/*
// @version 1
// @grant none
// ==/UserScript==
console.log("test");The script does not always run when I start firefox from command line like this :
On Linux firefox "https://www.dokuwiki.org/dokuwiki?do=login§ok="
On Windows & 'C:\Program Files\Mozilla Firefox\firefox.exe' "https://www.dokuwiki.org/dokuwiki?do=login§ok="
The same behavior happens when the URL is the start page for Firefox.
When I reload the page, the script runs.
I tested with ViolentMonkey and it doesn't seem affected. Reacted by Nathan Phillip Brink and Cerberus-tm Activitylmfont commented on Jun 6, 2021 Could not replicate on Linux with Firefox 89. Tried 5 times from a cold start. Possibly some kind of race condition? xpxaxsxi commented on Sep 17, 2024 This bug is very much alive, the following script does not run in Windows (tested on Windows 11)
--when using a url with firefox.exe in command line
--when Firefox has setting open earlier windows ON
Refreshing a such page always works
Fresh Firefox profiles and adding GM to that, that does not help
EDIT: ViolentMonkey has no problems, just checked out that
// ==UserScript==
// @name Anonyme Script 387564
// @match https://www.wikipedia.org/*
// @version 1
// @grant none
// ==/UserScript==
console.log("test");
binki commented on Feb 14, 2025 I am also experiencing scripts not loading until I reload certain pages if session restore is enabled. I assume Greasemonkey just isn’t loaded yet when the session is being restored? Maybe there’s some event it could hook into so that it can prevent pages from loading before it is ready?
Perhaps the OP failed to mention that they are talking about launching firefox, not opening a new tab in an existing instance. Cerberus-tm commented on Feb 14, 2025 This would explain why I regularly find tabs where scripts do not seem to have loaded. I wonder whether Greasemonkey could fix this, or whether it is a Firefox issue? A race condition does seem likely. binki commented on Feb 14, 2025
Maybe there’s some event it could hook into so that it can prevent pages from loading before it is ready?
Actually, this is a bad idea since it would impact performance. Instead, Greasemonkey should apply itself to already-loaded tabs once it is loaded if there is a race condition between loading initializing extensions and loading tabs/restoring session. (I.e., does Firefox guarantee that webNavigation.onCommitted for session restore will be observed by extensions which are installed prior to Firefox being launched or not? If not, then Greasemonkey has to somehow compensate).
I have not tried debugging things, but I think there is a race condition in Greasemonkey itself: if
|
const userScriptIterator = UserScriptRegistry.scriptsToRunAt(detail.url); |
(which is a non-asynchronous search for scripts applicable to a window) is run before
|
async function loadUserScripts() { |
runs to completion, Greasemonkey may incorrectly conclude that no scripts apply to the tab. It looks like the fix would be to have onNavigation wait for userScriptsReady to resolve prior to calling UserScriptRegistry.scriptsToRunAt(). This race condition could be exacerbated for debugging purposes by adding a delay in openDb(). That would probably be the only way to reliably reproduce this issue. arantius commented on Feb 14, 2025 Yeah in theory scriptsToRunAt() could/should await userScriptsReady. But as noted above, script execution is already unreliable at launch time. I'm not aware of a webExtensions API that could make it reliable. So never considered it important enough to worry about. Cerberus-tm commented on Feb 14, 2025 Hmm I don't know how much work this would be. But anything to increase the chance that the right script might run would be nice. So is it at least partly an issue of Firefox itself? binki commented on Feb 17, 2025
But as noted above, script execution is already unreliable at launch time.
Can you clarify where this is noted? I made some speculative comments, but I do not actually know what guarantees Firefox does or doesn’t make. It seems reasonable to me that it might guarantee to allow all traditional extensions to register event handlers prior to delivering those events on session restore or launch. It is more difficult to experiment whether or not this is happening when Greasemonkey has its own race condition. Is there any chance this race condition could be closed and a new release rolled? Is there a requirement that chrome.webNavigation.onCommitted be handled synchronously?
I am pretty sure that I am seeing this same failure to run scripts during launch in Android too, just as another observation. arantius commented on Feb 22, 2025
Is there any chance this race condition could be closed and a new release rolled?
Pull requests gladly reviewed. Especially for the probably-one-line race condition discussed.
For the real/whole fix: given how limited (only at launch time, and I suspect (confirmation or refutation would be nice) only for those tabs that load immediately at launch time) the problem is, and how easy (hit reload) it is to work around: only a very clean/easy/simple/good fix is likely to be merged. (I.e. a large/complex workaround with state tracking and the likelihood of affecting all page loads in the future and/or containing other new bugs: probably not.) binki commented on Feb 24, 2025
Pull requests gladly reviewed. Especially for the probably-one-line race condition discussed.
Thanks! Now, it is close to a one-liner, but it can’t literally be a one liner. I can get it down to 2 code lines if I use async and await. I will try to submit a PR shortly.
Unfortunately, in my experimentation, I found that this change did not solve this issue for me. When I added some printf-debugging, I found that the window between when the extension loaded and the script registry finished loading was very short (e.g., 200ms) and most webNavigation.onCommitted events only started pouring in about 800ms after that and only for subframes of sessionrestore tabs or delayed sessionrestore tabs. This is evidence that Firefox won’t wait for the extension to load prior to loading sessionrestore or launch URLs.
P.S., I think that, technically, the check for getGlobalEnabled() suffers from the same race condition as the data store. I think the right thing to do is fix this one too. Otherwise, if we come up with an airtight fix for this issue of scripts failing to run on boot-up, leaving getGlobalEnabled() unfixed will result in Greasemonkey incorrectly assuming that it is enabled while it loads the setting’s value from storage. This would be a very bad and confusing user experience. I will prepare a PR for this too and I will be seeking your guidance on what approach is appropriate for that.
For the real/whole fix: given how limited (only at launch time, and I suspect (confirmation or refutation would be nice) only for those tabs that load immediately at launch time) the problem is, and how easy (hit reload) it is to work around: only a very clean/easy/simple/good fix is likely to be merged. (I.e. a large/complex workaround with state tracking and the likelihood of affecting all page loads in the future and/or containing other new bugs: probably not.)
As mentioned above, unfortunately, this sort of approach is the only way to solve this issue.
In my own experimentation and testing, I found a solution where most of the complexity lies in the mechanism which searches for already-open tabs and only adds minimal complexity to handling of future webNavigation.onCommitted events. It does involve temporarily tracking the list of seen tabIds and frameIds (which I think cannot be avoided due to the asynchronous nature of the involved APIs for tab and frame enumeration). I will need some time to clean this up before I can submit a PR for it. We will see if it is simple enough to be considered at that time. added a commit that references this issue on May 26, 2026This issue will close once commit 1718951 is merged into the 'master' branch.1718951
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|