WebDriver BiDi script.addPreloadScript generated functions not working after a few navigations
Categories
(Remote Protocol :: WebDriver BiDi, defect, P3)
Tracking
(firefox-esr115 unaffected, firefox-esr140 unaffected, firefox152 wontfix, firefox153 fixed, firefox154 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox152 | --- | wontfix |
| firefox153 | --- | fixed |
| firefox154 | --- | fixed |
People
(Reporter: hadaionut, Assigned: Sasha)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [webdriver:m20][webdriver:relnote])
Attachments
(5 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0
Steps to reproduce:
On Firefox 151 using both a puppeteer script and a script that uses WebDriver Bidi commands, i am adding a function to the window object using script.addPreloadScript.
const preloadFunction = `
() => {
window.myInjected = {
printVisible(text = 'Hello from myInjected.printVisible()') {
console.log('[myInjected] ' + text);
},
};
}
`;
await bidi.send('script.addPreloadScript', {
functionDeclaration: preloadFunction,
contexts: [context],
});
On wikipedia.org i am adding that function, and calling it from the devtools after each navigation. After 3 navigations the function is available but calling it does nothing.
To reproduce the bug run the provided script, navigate to a website, follow a link a few times and try to call window.myInjected.printVisible()
Actual results:
Nothing. The function was called but nothing inside it was actually executed. No error was logged or thrown.
Expected results:
I would expect it to work like previous versions of firefox where the registered functions are working.
Updated•1 month ago
|
Does that only happen when you navigate manually or as well when you are using WebDriver BiDi navigation commands? Also are you saying it was working in Firefox 150? If not which version worked last for you?
| Reporter | ||
Comment 2•1 month ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #1)
Does that only happen when you navigate manually or as well when you are using WebDriver BiDi navigation commands? Also are you saying it was working in Firefox 150? If not which version worked last for you?
It was working in firefox 150. I have not tried it using BiDi navigation commands
| Reporter | ||
Comment 3•1 month ago
|
||
Update: I have also tried doing it using navigation commands and the same thing happens(In reply to Ionut Hada from comment #2)
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #1)
Does that only happen when you navigate manually or as well when you are using WebDriver BiDi navigation commands? Also are you saying it was working in Firefox 150? If not which version worked last for you?
It was working in firefox 150. I have not tried it using BiDi navigation commands
Hm, all the changes for Firefox 151 can be found in this Bugzilla query. Sadly nothing obvious stands out here.
I also created a webdriver test which navigates through pages and checks that the preload script is still registered. It's not failing at all for me with the Firefox 151 release or in a recent Nightly build of Firefox.
Here some suggestions for you:
- Start the WebDriver session with the preference
remote.log.levelset toTraceto get tracing logs - Update your script to navigate automatically to those pages that you were loading manually
- Try a Nightly build of Firefox to check if it's happening there as well.
| Reporter | ||
Comment 5•1 month ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #4)
Created attachment 9596331 [details]
webdriver testHm, all the changes for Firefox 151 can be found in this Bugzilla query. Sadly nothing obvious stands out here.
I also created a webdriver test which navigates through pages and checks that the preload script is still registered. It's not failing at all for me with the Firefox 151 release or in a recent Nightly build of Firefox.
Here some suggestions for you:
- Start the WebDriver session with the preference
remote.log.levelset toTraceto get tracing logs- Update your script to navigate automatically to those pages that you were loading manually
- Try a Nightly build of Firefox to check if it's happening there as well.
I will try the suggested steps, i also see the preload scripts registered, but when i try to call a function created by the preload script nothing happens. Even if the function is visibile in devtools and its .ToString() method returns what i would expect
| Reporter | ||
Comment 6•1 month ago
|
||
I have updated to:
- using firefox nightly 153.0a1
- setting remote.log.level to trace,
- making navigation with bidi commands
- calling my test function using script.evaluate
My preload function is set to display something in the dom so we can see this is executed and return a string, the return works correctly but the display in the dom is missing after the 3rd navigation.
new script: https://pastebin.com/h2qrK4iJ
logs: https://pastebin.com/hUwQsNYN
Here the trace logs as direct attachment so that it's not getting lost by the policy of pastebin.com.
Ionut, how reliably can you reproduce this bug? Does it happen all the time? If yes, could you maybe use mozregression to find the regression range? You should start with --good 150 --bad 151. We would appreciate your help given that we still have problems to reproduce - maybe it's platform related. Thanks!
| Reporter | ||
Comment 9•1 month ago
|
||
Hello, the bug is 100% reproduceable, it happens on windows on every run after the same number of navigations, this is the list of pages i am going through and the last one is always the one with the bug:
'https://www.wikipedia.org/' ->, 'https://en.wikipedia.org/wiki/WebDriver', -> 'https://en.wikipedia.org/wiki/Firefox', -> 'https://en.wikipedia.org/wiki/Browser_engine',
Aditionally, after running mozregression, i think i narrowed it down to this range:
3:19.04 INFO: Test command result: 0 (build is good)
3:19.04 INFO: Narrowed integration regression window from [fd22eead, 64b3c913] (3 builds) to [f9082c93, 64b3c913] (2 builds) (~1 steps left)
3:19.04 INFO: No more integration revisions, bisection finished.
3:19.04 INFO: Last good revision: f9082c9319910b607e1b028c49b3bd353ab56f5a
3:19.04 INFO: First bad revision: 64b3c91301e828515c9f7d6d6ff8bf5e0f15a47e
3:19.04 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f9082c9319910b607e1b028c49b3bd353ab56f5a&tochange=64b3c91301e828515c9f7d6d6ff8bf5e0f15a47e
That's good to hear that you can always reproduce it. As well thanks for the output of the mozregression run. I wonder why it didn't continue to bisect on autoland to actually find the exact causing commit. But it doesn't matter because I can see bug 1985997 in that list which is exactly about script.addPreloadScript.
Surprisingly this goes back to Firefox 149 and not 151 as you originally pointed out, so can you please verify again that this reported range from mozregression is correct?
Updated•1 month ago
|
| Reporter | ||
Comment 11•1 month ago
|
||
Hello, i have a few updates:
- I am pretty sure the source of the problem is somewhere in Firefox 149, unfortunately i am having issues installing that version through mozregression, because it keeps crashing with the following: (note it works fine with any other version)
0:04.27 INFO: Using date 2026-01-12 for release 148
0:06.95 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2026/01/2026-01-12-21-15-23-mozilla-central/firefox-149.0a1.en-US.win64.zip
===== Downloaded 100% =====
0:14.96 INFO: Running mozilla-central build for 2026-01-12
0:18.27 INFO: Launching C:\Users\iioanandrei\AppData\Local\Temp\tmp4vc8808j\firefox\firefox.exe
0:18.27 INFO: Application command: C:\Users\iioanandrei\AppData\Local\Temp\tmp4vc8808j\firefox\firefox.exe --wait-for-browser -profile C:\Users\IIOANA~1\AppData\Local\Temp\tmpgeaywoke.mozrunner
0:18.29 INFO: application_buildid: 20260112211523
0:18.29 INFO: application_changeset: 63c7136296e4969d855be04bff78a536ed2108b5
0:18.29 INFO: application_name: Firefox
0:18.29 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:18.29 INFO: application_version: 149.0a1
0:30.05 WARNING: Process exited with code 3221225477
To reproduce the issue on 149 i have used puppeteer's browser downloader. That browser works fine and it is the first version that reproduces the issue.
2. In my previous tests i have made a mistake, the issue does not appear when you use bidi navigation commands, just manual interactions with the browser. (
3. When the issue happens in the devtools you can see that the affected function loses its autocomplete signature.
| Assignee | ||
Comment 12•1 month ago
|
||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Comment 13•1 month ago
|
||
Hey Ionut, could you try to reproduce with these code changes: https://hg-edge.mozilla.org/try/rev/01917d883112826cdaa1e706fd65dfc617657ee4. It seems to work for me, but just to be certain, since I couldn't reproduce it consistently.
Just as additional information for the mentioned change there is a CI build of a Firefox available including that commit. Click in the lower pane on Artifacts and Debugging Tools and then download the file target.zip. Or here the direct link. That way you won't have to build Firefox yourself.
| Reporter | ||
Comment 15•1 month ago
|
||
Hello, I have tested on this build and the problem seems to be fixed.
In what version of firefox do you think this will be released?
Comment 16•1 month ago
|
||
| Assignee | ||
Updated•1 month ago
|
| Assignee | ||
Updated•1 month ago
|
Comment 17•1 month ago
|
||
| bugherder | ||
It would be good to get this patch uplifted given that we just released the first beta 153b1.
Comment 19•1 month ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined/Reason for urgency: User will continue experiencing the regression
- Code covered by automated testing?: yes
- Fix verified in Nightly?: yes
- Needs manual QE testing?: no
- Steps to reproduce for manual QE testing: None
- Risk associated with taking this patch: low
- Explanation of risk level: It's a small change that shouldn't affect the general automation usage.
- String changes made/needed?: None
- Is Android affected?: yes
| Assignee | ||
Comment 20•1 month ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D306979
Updated•1 month ago
|
Updated•1 month ago
|
Comment 22•1 month ago
|
||
| uplift | ||
Description
•