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)

55 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox55 --- wontfix
firefox56 --- fixed
firefox57 --- fixed

People

(Reporter: bugzilla, Assigned: baku)

Details

Crash Data

Attachments

(5 files)

Attached file notizfenster.php
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
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)
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
Thanks Chnutz for the regression window.

NI :baku as he fixed bug 1347817.
Flags: needinfo?(htsai) → needinfo?(amarchesini)
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
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)
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)
> 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!
For comment 14.
Flags: needinfo?(bugzilla)
Done.
The bug is reproducible in nightly.
Flags: needinfo?(bugzilla)
Back to you, baku (rhyme unintentional)
Flags: needinfo?(amarchesini)
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!
Ah, you need a flag?! Sorry, here it is :-)
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)
Let's keep trying to work with Chnutz to get a reliable STR (that means "steps to reproduce" :)
Flags: needinfo?(overholt)
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)
Oops, again the flag...
Flags: needinfo?(overholt)
Flags: needinfo?(amarchesini)
I can't reproduce either on Windows 10 in Nightly.
Flags: needinfo?(overholt)
I can't reproduce in release, either.
Maybe someone in QA can reproduce this?
Flags: needinfo?(ryanvm)
Keywords: qawanted
https://download.teamviewer.com/download/TeamViewer_Setup.exe ?

My ID: 223 660 384
Pass: 4807
Keywords: qawanted
Flags: needinfo?(overholt)
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)
Got it:
FF 55 
plus the combination mysql/javascript
plus...
...Kaspersky Internet Security!
How should we/I react now?
Flags: needinfo?(ryanvm)
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)
OK, thank you all!
I write to kaspersky support, too, issue number there is INC000008205068
I'll inform you immediately when they answer.
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.
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)
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)
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.
Should we assume this also affects 56? Can someone follow up to check?
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.
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].
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
(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.
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)
(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)
I can reproduce it. Working on it.
Flags: needinfo?(amarchesini)
Attached patch ws.patchSplinter Review
Flags: needinfo?(jduell.mcbugs)
Attachment #8906649 - Flags: review?(bugs)
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+
Assignee: nobody → amarchesini
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
https://hg.mozilla.org/mozilla-central/rev/5b048319e830
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Do we want this to ride the trains to 57, or is it suitable for late uplift to beta56?
Flags: needinfo?(amarchesini)
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 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+
You need to log in before you can comment on or make changes to this bug.