1350833 - Could not access window created using window.open('about:blank' .... code

Status: NEW

(Firefox for iOS :: General, defect)

Description

[Bhavna]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

- Open url https://bhavnapanchal.github.io/firefoxpopuptest.github.io/
- Click on "click me" button of html page.


Actual results:

- After click on "click me" button it open blank about:blank window.
- New window remain there.


Expected results:

- After click on "click me" button it open blank about:blank window.
- Suppose to close it after 3 seconds.

Comment 1

[Bhavna]

I already create pull request for this issue.
https://github.com/mozilla-mobile/firefox-ios/pull/2484

Comment 2

[Bhavna]

@Stephan

Did not get your comment.

This issue occur in Firefox-iOS.

Comment 3

[Stephan Leroux [:sleroux]]

Sorry - I was just nominating this bug for our triage meeting for tomorrow so we can discussion it's priority and scheduling.

Comment 4

[Bhavna]

@Stephan

Ok, In that case here I am sharing video that showing issue which might help you.

https://drive.google.com/file/d/0B7fztZykJUJMXzhhbGRmdkkxaVE/view?usp=sharing

Regards
Bhavna.

Comment 5

[Stephan Leroux [:sleroux]]

Let's see how Safari handles this case on mobile before whitelisting popups for about: pages. Keeping nomimated for now.

Comment 6

[Justin D'Arcangelo [:justindarc]]

The proof-of-concept at https://bhavnapanchal.github.io/firefoxpopuptest.github.io/ works on Mobile Safari, but I'm not certain if this pull request contains the proper fix. There may just be an issue somewhere in WindowCloseHelper.js.

Comment 7

[Bhavna]

Hi All,

Sorry to interrupt your conversation but I have something to share which might help.

@justin
After reading your comment I spend some time to investigate on ur direction and here is what I found.

I investigate two files "WindowCloseHelper.swift" and "WindowCloseHelper.js"

- If we do not whitelisting popups for about: pages. (without my code)
1. We can successfully add WindowCloseHelper.js into new tab
   Line 21: tab.webView!.configuration.userContentController.addUserScript(userScript)
   execute successfully.

2. function didReceiveScriptMessage message: WKScriptMessage never call
   Line 30: func userContentController(_ userContentController: WKUserContentController, didReceiveScriptMessage message: WKScriptMessage).

- If we do whitelisting popups for about: pages. (with my code)
1. We can successfully add WindowCloseHelper.js into new tab
   Line 21: tab.webView!.configuration.userContentController.addUserScript(userScript)
   execute successfully.

2. function didReceiveScriptMessage message: WKScriptMessage always call
   Line 30: func userContentController(_ userContentController: WKUserContentController, didReceiveScriptMessage message: WKScriptMessage).


One more thing is I also investigate chrome as it is also open source.
if we do same think with chrome(return nil in delegate method createWebViewWith configuration) it also have same issue.

Please let me know if you need any other information.

Regards,
Bhavna.

Comment 8

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Bhavna, can you please let us know why this patch is important? Can you give some real use cases? How do other mobile browsers on iOS handle this?

Comment 9

[Bhavna]

> Bhavna, can you please let us know why this patch is important? 
- This patch is important because, I believe this is how normal browser suppose to behave when javascript developer want to open new window using var newWindow = window.open(‘about:blank') and want to close it or modify it.


> Can you give some real use cases? 
- There could be many use cased let me explain you with below.
- There is a situation where online examination site owner wants javascript developer to open new window for question and close it when time is out.

Now what javascript developer will do is open new window and store reference to the variable and close it when time out.

But in firefox this logic will not work and window will be still there.


> How do other mobile browsers on iOS handle this?
- Other browser handle this case very well I also share video of safari and chrom I also do check for code of chrom they do not have such filter or validation while opening new window.


Question] Why fire fox have whitelist/filter to open new window ?
Can you explain me issue firefox may have if we remove whitelist logic?
or give me link from where i can understand the same.

Sorry for late reply.

Thanks&regards
Bhavna panchal

Comment 10

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Attachment: PR https://github.com/mozilla-mobile/firefox-ios/pull/2484

Comment 11

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Do we still need this patch? I remember that we did some work on this too?

Comment 12

[Justin D'Arcangelo [:justindarc]]

Yes, we do. One important change I'd like to see though is that this comment about the line of code being changed in the PR is completely incorrect:

```
/// List of schemes that are allowed to open a popup window
private let SchemesAllowedToOpenPopups = ["http", "https", "javascript", "data", "about"]
```

These aren't schemes allowed to *open* a popup, they're actually schemes that are allowed to *be opened* as a popup (i.e., they're not the source schemes, they're the destination schemes).

If you follow where `SchemesAllowedToOpenPopups` is being used, this becomes clearer. In the `createWebViewWith` WKUIDelegate method, we check the that the scheme of the URL being opened is contained in `SchemesAllowedToOpenPopups`.

In this case, I'd also rename `SchemesAllowedToOpenPopups` for clarity.

I can see this through to completion if you agree with this analysis. Let me know.

Comment 13

[Bhavna]

@Justing

I wonder why this list(Valid schemes which allow to open popups) exists in code.

If we remove this list (i.e allow all schemes to open popups). There will be any problem ?

I debug and check there is no such kind of list in chrome.

Comment 14

[Bhavna]

My another concern is, Is this logic fulfill what explain in below?
https://developer.mozilla.org/en-US/docs/Web/API/Window/open

special what return about "Return value".

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:jeevans, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.