Closed
Bug 1392202
Opened 7 years ago
Closed 7 years ago
Since the last Update 55.0.2 I'va a problem with javascript in a frameset.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla57
People
(Reporter: bugzilla, Assigned: baku)
Details
Crash Data
Attachments
(5 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170814072924 Steps to reproduce: Inside a frame in a frameset I want to use this JS to reopen the frameset (index.php) after write form data in a database with the new data: <script language='javascript'> window.open('index.php?ID=".$_POST["Ident"]."&WV=1','_parent','') </script> </body> The whole file is attached, the issue happend at line 43 and below. Actual results: Firefox freezed after writing the data when it has to reload the frameset since v55.0.2 Expected results: Before the update the function has worked and opened the frameset without a problem. I tested the function outside a frameset and it works, so it would be a problem with the combination frameset - javascript - php Unfortunately I cannot give you the link to the oroginal frameset because it's an 'intranet'. Do you have an idea?! Greetings Chnutz
- I tried it in FF v54 and it still works as before; - I tried it in a frameset without the database-connection in php and it works, too: https://www.chnutz.de/test/fftest/index.php?ID=35&WV=1 - I tried it in FF v55 Save Mode with the error as described. So the issue happens only with PHP-Database Connection and the following JS in FF v55
Comment 2•7 years ago
|
||
Hi Chnutz, thanks for reporting this issue. Per your comment, this sounds like a regression in FF v55. Would you mind using mozregression tool [1] to help us get the regression window? Thanks. [1] https://github.com/mozilla/mozregression
Flags: needinfo?(bugzilla)
Hi Hsin-Yi Tsai, Thank you and yes, I'll try it, download and installing is already done :-)
Flags: needinfo?(bugzilla)
Done. Do you have recieved the log autmatically or should I post it?
Flags: needinfo?(htsai)
Comment 5•7 years ago
|
||
Please post the regression window or the regression bug here, thank you.
Flags: needinfo?(htsai)
MozRegression-Screenshot
Flags: needinfo?(htsai)
Attachment #8901468 -
Flags: feedback+
Logfile of MozRegression
Attachment #8901470 -
Flags: feedback+
Sorry, it's my first use of this tool, where can I find the bug, in the logfile or elsewhere?
After a second round I find this: 2017-08-27T01:44:40: DEBUG : Starting merge handling... 2017-08-27T01:44:40: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=235e1d29916fc30848b796ef9b416ec3932a743b&full=1 2017-08-27T01:44:41: DEBUG : Found commit message: Bug 1347817 - Principal must always have a valid origin - part 6 - fixing tests, r=ehsan 2017-08-27T01:44:41: INFO : The bisection is done. 2017-08-27T01:44:41: INFO : Stopped
Comment 10•7 years ago
|
||
Thanks Chnutz for the regression window. NI :baku as he fixed bug 1347817.
Flags: needinfo?(htsai) → needinfo?(amarchesini)
Reporter | ||
Comment 11•7 years ago
|
||
Thanks for working on my beloved firefox :-) If you or "amarchesini" need more help or information, please feel free to contact me. Unfortunately I'm not allowed to open the intranet site for you but if you need to look at the problem we could use a teamviewer session on my pc or something like this. Greetings Chnutz
Assignee | ||
Comment 12•7 years ago
|
||
Hi, first of all, thanks for your bug report. I have a couple of questions: Can I use https://www.chnutz.de/test/fftest/index.php?ID=35&WV=1 to test the bug? Can you tell me how to reproduce this issue step by step? Is this bug reproducible in nightly?
Flags: needinfo?(amarchesini) → needinfo?(bugzilla)
Reporter | ||
Comment 13•7 years ago
|
||
Hi Andrea, "Can I use https://www.chnutz.de/test/fftest/index.php?ID=35&WV=1 to test the bug?" No, unfortunately not, the issue's not happen there. If you want to test we could open a teamviewer-session on my pc and I'll connect to the intranet with VPN, there you can test. This evening I'll try to establish a test environment with database, php and html. "Can you tell me how to reproduce this issue step by step?" There's a button "Notiz speichern" in the file "notizfenster.php" (see above) to save the input in the database and reopen the whole frameset including the new data (look around line 43). When I click the button, the "load"-icon is shown next to the adress bar immediately and the task manager shows me that firefox.exe is still using cpu, but is also shown as inactive. Then nothing more happens for minutes and at last I have to close firefox with the task manager because it doesn't react on any further click. The mysql-query is fine, after restart I always find the input data in the database. So the issue must happen when I try to reopen the frameset with <script language='javascript'> window.open('index.php?ID=".$_POST["Ident"]."&WV=1','_parent','') </script> </body> AND a mysql-query before. When I inactivate the mysql-part AND/OR the JS-part, the issue seems not to happen. "Is this bug reproducible in nightly?" Sorry, I don't understand what you mean exactly with this question, can you explain it a little more or in other words?! Did you see the copy of the regression test above? This is not what you want to know?!
Flags: needinfo?(bugzilla)
Assignee | ||
Comment 14•7 years ago
|
||
> This evening I'll try to establish a test environment with database, php and > html. Thanks! I want to test it locally as well. > "Is this bug reproducible in nightly?" Sorry, I don't understand what you > mean exactly with this question, can you explain it a little more or in > other words?! Nightly is firefox 57: http://nightly.mozilla.org/ Thanks so much for your help!
Reporter | ||
Comment 16•7 years ago
|
||
Done. The bug is reproducible in nightly.
Flags: needinfo?(bugzilla)
Reporter | ||
Comment 18•7 years ago
|
||
The test environment for you is ready: http://paz-lab.com/mozillatest/index.php?ID=35 And: The nightly reacts a little different. When I use FF55 a complete hung up happens, in nightly only the tab is waiting for something. You can reproduce this with the test environment. Good luck and thank you for the help!
Reporter | ||
Comment 19•7 years ago
|
||
Ah, you need a flag?! Sorry, here it is :-)
Assignee | ||
Comment 20•7 years ago
|
||
I cannot reproduce it. What I have done is: 1. to open http://paz-lab.com/mozillatest/index.php?ID=35 on nightly (and/or 55). 2. write something in the textarea 3. press 'Notiz speichern' the page reloads and I see my message in the frame list under the frame form. Chnutz, is this the correct way to reproduce the issue? Andrew, can you find somebody helping me with the testing?
Flags: needinfo?(overholt)
Flags: needinfo?(bugzilla)
Flags: needinfo?(amarchesini)
Comment 21•7 years ago
|
||
Let's keep trying to work with Chnutz to get a reliable STR (that means "steps to reproduce" :)
Flags: needinfo?(overholt)
Reporter | ||
Comment 22•7 years ago
|
||
Your way to test it is correct and when I try it in the same way, the issue still happens. Maybe it depends on the operation system? I use Windows 10 Professional 64bit, the other group Windows 7 Professional 64bit on 4 different pc, all with the same issue.
Flags: needinfo?(bugzilla)
Reporter | ||
Comment 23•7 years ago
|
||
Oops, again the flag...
Flags: needinfo?(overholt)
Flags: needinfo?(amarchesini)
Comment 24•7 years ago
|
||
I can't reproduce either on Windows 10 in Nightly.
Flags: needinfo?(overholt)
Comment 25•7 years ago
|
||
I can't reproduce in release, either.
Comment 26•7 years ago
|
||
Maybe someone in QA can reproduce this?
Flags: needinfo?(ryanvm)
Keywords: qawanted
Reporter | ||
Comment 27•7 years ago
|
||
https://download.teamviewer.com/download/TeamViewer_Setup.exe ? My ID: 223 660 384 Pass: 4807
Keywords: qawanted
Comment 28•7 years ago
|
||
I can't reproduce on Win10 or Ubuntu 17.04. Maybe someone from Rares' team will have better luck.
Flags: needinfo?(ryanvm) → needinfo?(rares.bologa)
Reporter | ||
Comment 29•7 years ago
|
||
Got it: FF 55 plus the combination mysql/javascript plus... ...Kaspersky Internet Security!
Comment 31•7 years ago
|
||
I don't have Kaspersky available to test with, but the team I mentioned in comment 28 does. Assuming they can reproduce using Kaspersky & the STR from comment 20, we can hopefully try to figure out what they're doing that's interfering with Firefox' operation. Keep in mind that this could very well end up being an issue that requires fixing on their end, however. Won't know for sure until we can reproduce, though.
Flags: needinfo?(ryanvm)
Reporter | ||
Comment 32•7 years ago
|
||
OK, thank you all! I write to kaspersky support, too, issue number there is INC000008205068 I'll inform you immediately when they answer.
Comment 33•7 years ago
|
||
Reproduce the issue on Windows 10 with Kaspersky Internet Security 18.0.0.405(b) as follows: with latest Nightly 57.0a1, build ID 20170830220349.
Comment 34•7 years ago
|
||
Reproduce the issue on Windows 10 x64 with Kaspersky Internet Security 18.0.0.405(b) installed as follows: - with latest Nightly 57.0a1, build ID 20170830220349 - current tab hang an crash can be found in about:crashes, with signature [@IPCError-browser | ShutDownKill] - https://crash-stats.mozilla.com/report/index/fcf83f68-7ca1-4499-be74-4e6f50170831 - with latest release 55.0.3 - complete hung up of the browser, crash with signature [@IPCError-browser | ShutDownKill] - https://crash-stats.mozilla.com/report/index/4db22f50-7d62-4af7-9e79-c756a0170831 Please note that the issue was not reproducible before I installed Kaspersky Internet Security 18.0.0.405(b). On another test machine, with Windows 10 X64 and with Kaspersky Endpoint Security 10 installed, the bug is not reproducible.
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Flags: needinfo?(rares.bologa)
Updated•7 years ago
|
status-firefox55:
--- → affected
status-firefox57:
--- → affected
Comment 35•7 years ago
|
||
I don't know what we should do now. Is there some workaround we can produce (seems like the ShutDownKill issues in this particular instance are coming from WebSocket code in Gecko)? Or do we have to wait for Kaspersky to do something? Maybe Jason has heard about something with WebSockets and Kaspersky? Or maybe baku knows (he's somewhat familiar with the DOM side of WebSockets)?
Flags: needinfo?(overholt) → needinfo?(jduell.mcbugs)
Comment 36•7 years ago
|
||
I'll try emailing BrowserIssues@kaspersky.com with information on this bug. We also can ask Alexey who is talking with us in https://bugzilla.mozilla.org/show_bug.cgi?id=1384327#c17 about another issue.
Comment 37•7 years ago
|
||
Should we assume this also affects 56? Can someone follow up to check?
Reporter | ||
Comment 38•7 years ago
|
||
I've informed kaspersky support about yout tests and this thread and tested some of their suggestions: Only the following KIS components provocates the hung up: - Web Antivirus; - Softwaremanager; - Data Collection Protection. (I use the German Version, so I don't know the exact English labels) No effect: - File AV; - Program Control; - Firewall; - Protection against Network Attacs; - Program Update; - Aktivitymonitor. To declare FF in KIS as "vertrauenswürdig" (trusted) has no positive effect.
Comment 39•7 years ago
|
||
I can confirm the issue is also reproducing on latest Beta 56.0b8, with the behavior from Nightly: current tab hangs and a crash can be found in about:crashes, with signature [@IPCError-browser | ShutDownKill].
Comment 40•7 years ago
|
||
We investigate the problem in Kaspersky Lab, and came to conclusion that there is race condition between creating WebSocket connection and DOM destruction, with possible leads to deadlock. Attach to the comment you will find the minimum example, which cause FF hangs. Reproducing not stable, in our desktops FF hangs approximately after 30 clicks on “submit” button.
Comment 41•7 years ago
|
||
(In reply to Alexey Totmakov from comment #40) > Created attachment 8904708 [details] > Bug_1392202_min_repro.zip > > We investigate the problem in Kaspersky Lab, and came to conclusion that > there is race condition between creating WebSocket connection and DOM > destruction, with possible leads to deadlock. Attach to the comment you will > find the minimum example, which cause FF hangs. Reproducing not stable, in > our desktops FF hangs approximately after 30 clicks on “submit” button. No Kaspersky software require reproducing bug.
Reporter | ||
Comment 42•7 years ago
|
||
I received now an update from Kaspersky Support. With KIS 18.0.0.405(b) all seems well, the issue is not come up any longer, I've tested it with the original frameset and with the test frameset. Thank you all!
Flags: needinfo?(alexey.totmakov)
Comment 43•7 years ago
|
||
(In reply to Chnutz from comment #42) > I received now an update from Kaspersky Support. > With KIS 18.0.0.405(b) all seems well, the issue is not come up any longer, > I've tested it with the original frameset and with the test frameset. > Thank you all! I do not think that the problem is gone. There is race condition in FF, and it is shoot without installed Kaspersky, I attached the minimal example. Perhaps, patch B just reduce probably of deadlock in FF.
Flags: needinfo?(alexey.totmakov)
Assignee | ||
Comment 45•7 years ago
|
||
Flags: needinfo?(jduell.mcbugs)
Attachment #8906649 -
Flags: review?(bugs)
Comment 46•7 years ago
|
||
Comment on attachment 8906649 [details] [diff] [review] ws.patch We definitely need a test here. Perhaps add something to the test which was added for bug 1384658.
Attachment #8906649 -
Flags: review?(bugs) → review+
Updated•7 years ago
|
Assignee: nobody → amarchesini
Comment 47•7 years ago
|
||
Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5b048319e830 WebSocket CTOR should not try to look for the topmost window if the opener's top ancestor is equal to the current window top ancestor, r=smaug
Comment 48•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5b048319e830
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Comment 49•7 years ago
|
||
Do we want this to ride the trains to 57, or is it suitable for late uplift to beta56?
Flags: needinfo?(amarchesini)
Assignee | ||
Comment 50•7 years ago
|
||
Comment on attachment 8906649 [details] [diff] [review] ws.patch Approval Request Comment [Feature/Bug causing the regression]: WebSocket [User impact if declined]: content process can freeze. [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: a test is attached [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: low [Why is the change risky/not risky?]: A simple check on the parentWindow top-level being different than the inner window top level. [String changes made/needed]: none
Flags: needinfo?(amarchesini)
Attachment #8906649 -
Flags: approval-mozilla-beta?
Comment 51•7 years ago
|
||
Comment on attachment 8906649 [details] [diff] [review] ws.patch Fix for a high volume freeze/crash in the content process. Let's take this for beta 12.
Attachment #8906649 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 52•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/a085ae94f23a
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•