On Mon, Jan 5, 2015 at 11:17 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
So my question is: is the spec incorrect in that it should reflect reality?
Or are browsers incorrect and we should be hounding them to fix this
behavior?
It depends on compatibility. It seems the Chrome team
On 2014-12-11 09:09, Simon Pieters wrote:
The spec's parsing rules of meta refresh causes infinite reloading on
some pages. In particular, the spec requires the url= to be present,
but there are pages that omit it. IE9 also requires url= apparently.
Gecko/Blink/WebKit allow url= to be omitted.
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote:
Basically window.opener.location.href = whatever works all
the time, regardless of origin restrictions, and pretty much works that
way across all browsers.
This seems to indicate that this behavior isn't allowed:
even when the two windows have different domains
Basically window.opener.location.href = whatever works all the time
Looks like Chrome, Firefox and Opera already differentiate between window
origins when the example is changed to
window.opener.location.href=javascript:alert(‘Gotcha');” - if
On 1/6/15 3:10 PM, Nicholas C. Zakas wrote:
Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well.
Not if you use rel=nofollow, per spec. Browser support there is still
spotty but
On 1/5/2015 5:07 PM, Boris Zbarsky wrote:
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote:
Am I just missing something?
Sorry, you're totally right. I was going off the comment in the Chrome bug.
If B _isn't_ a toplevel browsing context, then we'd still skip step 1
because A is not sandboxed...
On Tue, Jan 6, 2015 at 12:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/6/15 3:10 PM, Nicholas C. Zakas wrote:
Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well.
Not if you
On Mon, 10 Nov 2014, Florian Rivoal wrote:
:hover matches on the labeled control of a label element currently
matching :hover.
Similarly, :active interoperably matches on the labeled control of a
label element currently matching :active (and
Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well.
Not if you use rel=nofollow, per spec.
The spec doesn't mention that `rel=nofollow` should null out
`window.opener`. That
On 1/6/15 3:43 PM, James M. Greene wrote:
The spec doesn't mention that `rel=nofollow` should null out
`window.opener`. That behavior is only mentioned for `rel=noreferrer`.
Er, you're right. I meant noreferrer.
-Boris
On 2015-01-07 08:52, Simon Pieters wrote:
...
I hear (a) these pages have been broken in IE for a long time, and (b)
only 23 (?) pages in your DB are found.
Right.
So why not just leave them broken?
It's a worse user experience and it's a shorter path to interop to
change IE.
...
User
On Tue, 06 Jan 2015 08:35:54 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
On 2014-12-11 09:09, Simon Pieters wrote:
The spec's parsing rules of meta refresh causes infinite reloading on
some pages. In particular, the spec requires the url= to be present,
but there are pages that omit
In reply to Boris, it looks like the spec has changed its wording since the
Chromium bug was filed, and it now sounds like the navigations should be
allowed (consistent with existing browser behavior).
At the time (Jan 10, 2013), I posted a quote of the spec to
https://crbug.com/168988, comment
On 1/5/15 8:14 PM, Mat Carey wrote:
even when the two windows have different domains
Basically window.opener.location.href = whatever works all the time
Looks like Chrome, Firefox and Opera already differentiate between window origins
when the example is changed to
14 matches
Mail list logo
