Since the last Update 55.0.2 I'va a problem with javascript in a frameset.

RESOLVED FIXED in Firefox 56

Status

()

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: bugzilla, Assigned: baku)

Tracking

55 Branch
mozilla57
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox55 wontfix, firefox56 fixed, firefox57 fixed)

Details

(crash signature)

Attachments

(5 attachments)

(Reporter)

Description

2 years ago
Posted 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
(Reporter)

Comment 1

2 years ago
- 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)
(Reporter)

Comment 3

2 years ago
Hi Hsin-Yi Tsai,

Thank you and yes, I'll try it, download and installing is already done :-)
Flags: needinfo?(bugzilla)
(Reporter)

Comment 4

2 years ago
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)
(Reporter)

Comment 6

2 years ago
MozRegression-Screenshot
Flags: needinfo?(htsai)
Attachment #8901468 - Flags: feedback+
(Reporter)

Comment 7

2 years ago
Logfile of MozRegression
Attachment #8901470 - Flags: feedback+
(Reporter)

Comment 8

2 years ago
Sorry, it's my first use of this tool, where can I find the bug, in the logfile or elsewhere?
(Reporter)

Comment 9

2 years ago
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)
(Reporter)

Comment 11

2 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

2 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

2 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

2 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!
For comment 14.
Flags: needinfo?(bugzilla)
(Reporter)

Comment 16

2 years ago
Done.
The bug is reproducible in nightly.
Flags: needinfo?(bugzilla)
Back to you, baku (rhyme unintentional)
Flags: needinfo?(amarchesini)
(Reporter)

Comment 18

2 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

2 years ago
Ah, you need a flag?! Sorry, here it is :-)
(Assignee)

Comment 20

2 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)
Let's keep trying to work with Chnutz to get a reliable STR (that means "steps to reproduce" :)
Flags: needinfo?(overholt)
(Reporter)

Comment 22

2 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

2 years ago
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
(Reporter)

Comment 27

2 years ago
https://download.teamviewer.com/download/TeamViewer_Setup.exe ?

My ID: 223 660 384
Pass: 4807
Keywords: qawanted
(Reporter)

Updated

2 years ago
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)
(Reporter)

Comment 29

2 years ago
Got it:
FF 55 
plus the combination mysql/javascript
plus...
...Kaspersky Internet Security!
(Reporter)

Comment 30

2 years ago
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)
(Reporter)

Comment 32

2 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.
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?
(Reporter)

Comment 38

2 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.
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

Comment 40

2 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

2 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

2 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

2 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 44

2 years ago
I can reproduce it. Working on it.
Flags: needinfo?(amarchesini)
(Assignee)

Comment 45

2 years ago
Posted 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

Comment 47

2 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
https://hg.mozilla.org/mozilla-central/rev/5b048319e830
Status: NEW → RESOLVED
Last Resolved: 2 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)
(Assignee)

Comment 50

2 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 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.