Firefox 126.0, some variables are assigned with a gibberish value
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
People
(Reporter: zj2975, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0
Steps to reproduce:
I was debugging my web app, and I find one variable is assigned to a value that is not expected.
I believe there is memory trespassing in firefox.
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0"
The same problem happens to windows.
Actual results:
For example, the variable name is
parentStateName
And in debug console the value:
"server0.conn0.process34//source46"
Expected results:
The value above is NOT from any of my application, it seems to me this is a string from Firefox runtime
Comment 2•1 year ago
|
||
Moving this over to a potential component as I am not sure where this would fit best. If this is not the right, please change to a more suitable one.
Thanks!
We tested our web app on version 125.0.5 and Developer version 127, both are working well.
We tested our web app on version 125.0.3 and Developer version 127, both are working well.
Comment 5•1 year ago
|
||
Hi :zj2975,
Unfortunately, it will be hard for us to investigate this without more details. Is it possible to provide us some code that reproduces the problem?
(In reply to Bryan Thrall [:bthrall] from comment #5)
Hi :zj2975,
Unfortunately, it will be hard for us to investigate this without more details. Is it possible to provide us some code that reproduces the problem?
My web app is a complicated one and it is hard for me to figure out a minimal script to reproduce this problem.
If you can send me a guide to gather the trace log, I would like to help.
Comment 7•1 year ago
|
||
You might be able to use https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_watchpoints/index.html in the debugger to figure out when parentStateName was last modified.
If you are able to consistently reproduce the problem, that would be a really good start.
Comment 8•1 year ago
|
||
Since Firefox 127 is the current release and your webapp is working on that version, it sounds like the problem has happily resolved itself.
We would like to investigate this further, since we don't know what the original problem was and it might resurface in the future, but without more details we cannot. I'm going to mark this as incomplete, but if you are able to provide a testcase or the problem comes back, please reopen this bug or create a new one.
Description
•