preface

Recently, while learning about browsers, I talked about the issue of sharing renderers between browsers. The two pages that opener can be referenced to will be in the same rendering process. These two pages can be called: browse context groups. However, during the test, it was found that a opener should pay attention to the problem, although the reason is “man-made disaster”, but also be careful! Take a note of that and give you a reminder.

How to use

  1. The window.open method opens.
  2. Click on link A to open it.

Here we look at the second method test, first making sure that both A.html and B.HTML are on the same site.

Off-topic: the same site, they all have reference relationship, but cross-domain can not directly manipulate the previous page, but cross-domain can still get global, so the reference relationship is still in.

Click on the A.HTML link to jump to B.HTML. In this case, the entire window object in A can be accessed from B and referenced.

a.html:

< HTML > < head > < title > A < / title > < / head > < body > < A href = ". / b.h HTML "target =" _blank "> to b page < / A > < / body > < / HTML >Copy the code

b.html:

< HTML > <head> <title>B</title> </head> <body> I am B page </body> <script> console.log(window.opener); / / points to A page window. Opener. Document. The body. The style.css. Display = 'none' < / script > < / HTML >Copy the code

In Chrome browser, in page B of the above code, opener should print null!

Why is that? Logically speaking, it should be the same as the conjecture in front of us!

When chrome 88 updated its security policy, it defaulted to a link rel=’noopener’. Previously, it was rel=’opener’.

Well, that’s good news. Logically, we don’t have to worry about that, do we? The browser did that for us.

Problem of repetition

When I was checking a page, I saw the following code and got lost in thought. Take a look with me.

It’s the same environment as before, the only difference here is that when writing the code, someone accidentally wrote the wrong a.html target word:

< HTML > < head > < title > A < / title > < / head > < body > < A href = ". / b.h HTML "target =" _black "> to b page < / A > - the words are spelt wrong here < / body > < / HTML >Copy the code

b.html:

< HTML > <head> <title>B</title> </head> <body> I am B page </body> <script> console.log(window.opener); / / points to A page window. Opener. Document. The body. The style.css. Display = 'none' < / script > < / HTML >Copy the code

So that’s interesting, because if you write the wrong code, then target doesn’t work, right? Try running the code, okay? A page is still disappeared! And B can print out A’s window! Explain the security issues here!

The target property defaults to _blank behavior even though it is not set to _blank. Open links will still open in a new window.

The pitfalls are:

For safety, chrome88 will default to a tag rel=”noopener”, which is equivalent to a tag opener null. Not set for the other values! This will cause a new window to open if the developer accidentally sets it to a different value. Opener can also refer to previous pages, and if some developers rely only on the browser’s default security policy, then it’s a disaster!

The solution

It is strongly recommended to set rel=”noopener norefferrer” for all A tags to strengthen the explicit attribute to prevent this kind of problem!

The API is introduced

MDN also has a special introduction to the above problem:

Returns A reference to the window in which the current window is opened, for example: Window B is opened in Window A. opener returns A.

As for the interpretation of the attribute of opener, I believe we have been familiar with it before. Here we go straight to the introduction on MDN, for those of you who are not clear.

MDN Reference article:

Developer.mozilla.org/zh-CN/docs/…

Developer.mozilla.org/zh-CN/docs/…

Developer.mozilla.org/zh-CN/docs/…