Re: [whatwg] [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML
On Tue, 12 Jun 2012 20:38:08 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/12/12 4:47 AM, Simon Pieters wrote: The potentially CORS-enabled fetch algorithm ignores the state of the crossorigin attribute when the URL is same-origin. Hmm. On the face of it, this seems like a bug when open redirectors are involved... Is this what UAs implement in practice? If it redirects, it switches to CORS. However, there are some bugs in the spec... I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now. http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-enabled-fetch -- Simon Pieters Opera Software
Re: [whatwg] [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML
On 6/13/12 4:55 AM, Simon Pieters wrote: If it redirects, it switches to CORS. However, there are some bugs in the spec... I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now. Can we push this whole algorithm down into the CORS spec? It looks like at this point fetching-resources.html and the XHR spec are both trying to define the same algorithm (no CORS for same-origin, check origin on redirect, switch to CORS as needed, etc), and it would be pretty nice if they ended up actually defining it the same way. Simplest way to do that is to define it in the CORS spec and just reference it in the others, I'd think. -Boris
Re: [whatwg] [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML
On Wed, 13 Jun 2012 18:09:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/13/12 4:55 AM, Simon Pieters wrote: If it redirects, it switches to CORS. However, there are some bugs in the spec... I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now. Can we push this whole algorithm down into the CORS spec? It looks like at this point fetching-resources.html and the XHR spec are both trying to define the same algorithm (no CORS for same-origin, check origin on redirect, switch to CORS as needed, etc), and it would be pretty nice if they ended up actually defining it the same way. Simplest way to do that is to define it in the CORS spec and just reference it in the others, I'd think. Yeah or maybe even merge this algorithm, the fetch algorithm, and the cross-origin request algorithms. Currently it's extremely hard to follow. -- Simon Pieters Opera Software
Re: [whatwg] Navigation triggered from unload
On 06/12/2012 08:56 PM, Boris Zbarsky wrote: On 6/12/12 6:30 AM, James Graham wrote: Based on some tests ([1]-[5]), it seems that WebKit seems to cancel the navigation in the unload handler always, Opera seems to always carry out the navigation in the unload handler, and Gecko seems to follow WebKit in the cross-origin case and Opera in the same-origin case. In all cases the unload handler is only called once. [1] http://hoppipolla.co.uk/tests/navigation/003.html [2] http://hoppipolla.co.uk/tests/navigation/004.html [3] http://hoppipolla.co.uk/tests/navigation/005.html [4] http://hoppipolla.co.uk/tests/navigation/006.html [5] http://hoppipolla.co.uk/tests/navigation/007.html For what it's worth, we initially tried to do what you say WebKit does but ran into web compat issues. See https://bugzilla.mozilla.org/show_bug.cgi?id=371360 for the original bug where we blocked all navigation during unload and https://bugzilla.mozilla.org/show_bug.cgi?id=409888 for the bug where we changed to the current behavior. I believe the spec says what it says based on our implementation experience here... Hmm, so I wonder if the WebKit people consider it a problem that they don't pass the tests in those bug reports. I couldn't find any of the original sites still responding, so it's hard to know if there is still a compat. problem here. If there isn't, the greater conceptual simplicity of the WebKit model is quite appealing. P.S. Opera's behavior is not quite as simple as you describe: as far as I can tell it depends on whether the unload is happening due to the user typing something in the url bar or due to the user clicking a link, say. That seems to be true. On the other hand it appears that gecko will still respect navigation from unload even if the unload was triggered by explicit user interaction (e.g. by editing the address bar), as long as all the origins match, so you can end up at a different page to the one you expected. That is very surprising behaviour (although I see that you can argue that it is possible in other ways).
Re: [whatwg] [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML
On Wed, 13 Jun 2012, Simon Pieters wrote: On Wed, 13 Jun 2012 18:09:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/13/12 4:55 AM, Simon Pieters wrote: If it redirects, it switches to CORS. However, there are some bugs in the spec... I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now. Can we push this whole algorithm down into the CORS spec? It looks like at this point fetching-resources.html and the XHR spec are both trying to define the same algorithm (no CORS for same-origin, check origin on redirect, switch to CORS as needed, etc), and it would be pretty nice if they ended up actually defining it the same way. Simplest way to do that is to define it in the CORS spec and just reference it in the others, I'd think. Yeah or maybe even merge this algorithm, the fetch algorithm, and the cross-origin request algorithms. Currently it's extremely hard to follow. Anne and I plan to do so at some point but doing so would be a lot of work and we both have bigger fish to fry right now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] readyState transitions when aborting a document
On Fri, 20 Apr 2012, Henri Sivonen wrote: * Should window.stop() really not abort the parser like the spec seems to suggest? Looks like Opera is alone with the non-aborting behavior. The spec is wrong. Can you elaborate on this? How can you tell? * Should reaching interactive always involve firing DOMContentLoaded? Probably. Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Fri, 20 Apr 2012, Henri Sivonen wrote: On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 31 May 2011, Henri Sivonen wrote: Recently, there was discussion about changing media element state in the same task that fires the event about the state change so that scripts that probe the state can make non-racy conclusions about whether a certain event has fired already. Currently, there seems to be no correct non-racy way to write code that probes a document to determine if DOMContentLoaded or load has fired and runs code immediately if the event of interest has fired or adds a listener to wait for the event if the event hasn't fired. Are there compat or other reasons why we couldn't or shouldn't make it so that the same task that fires DOMContentLoaded changes the readyState to interactive and the same task that fires load changes readyState to complete? Fixed for 'load'. I don't see a good way to fix this for 'DOMContentLoaded', unfortunately. It turns out that Firefox has accidentally been running defer scripts after DOMContentLoaded. I haven't seen bug reports about this. Embracing this bug might offer a way to always keep the readystatechange to interactive in the same task that fire DOMContentLoaded. See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html On Wed, 25 Apr 2012, Jonas Sicking wrote: Hmm.. how long as that been the case? I thought that when we originally implemented @defer we ran them before DOMContentLoaded was fired for various internal sanity reasons as well as because it gave authors better migration paths. It seems nice to me to be able to depend on that all scripts have run by the time that DOMContentLoaded is fired. Except for async scripts of course, which are always unreliable as to when and which order they execute. I.e. async scripts is an explicit footgun, but I'd rather have fewer of those. I haven't changed the spec here. I don't really see what we gain by making the stop parsing algorithm different in this way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] played member expected behavior.
On Thu, 26 Apr 2012, Ian Hickson wrote:
On Thu, 26 Apr 2012, Paul Adenot wrote:
The played member [1] description of the media element states :
The played attribute must return a new static normalized TimeRanges
object that represents the ranges of the media resource, if any,
that the user agent has so far rendered, at the time the attribute
is evaluated.
Currently implementing this member in Gecko, we are wondering the
exact meaning of the 'rendered' term. If one seek in a video to a
location while being in a paused state, the user agent 'renders' the
frame at that location, since it is displayed on the screen. No audio
(if any) is rendered, though.
In that case, should we create an empty range starting and ending at
the time that was seeked to ? That means creating multiple empty
ranges if multiple seeks occur while being paused. Does the
'rendering' term implies that playback should occur ? This description
need clarification to specify the exact behavior to adopt.
Semantically, the name of the member itself ('played') seem to imply
playback.
I think playback probably is the most useful. The use case here was
updating a playback scrub bar with colour for where the user has already
watched the video, and zero-length entries aren't useful for that.
I've made a note of this e-mail to fix the spec, but in the absence of
further information or opinions from anyone else, I'd go with playback
as you suggest.
This is now fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should editable elements have placeholder attribute?
On Tue, 1 May 2012, Ryosuke Niwa wrote:
Would it be useful to have placeholder content attribute on elements
that are editable? (i.e. contenteditable=true).
According to the original WebKit bug 21286, this may reduce the amount
of code authors have to write.
contenteditable= is a low-level primitive for creating text editors.
It's not clear to me that there is much to be saved by adding a single
high level feature on top of this. You'd still have to do a ton of work to
make the editor work.
We can still make it easier to write the code, though. In fact, as far as
I can tell, it needn't be especially hard with existing specs:
[contenteditable]:empty::before { content: attr(data-placeholder) }
This wouldn't work if there's stray brs, etc, but if that's the only
problem here, we can provide new selectors for it, as some people
suggested. I recommend bringing that up in the CSSWG.
On Tue, 1 May 2012, Ryosuke Niwa wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node in the editable
element? Should we ignore things like br or collapsible spaces when
determining whether the element is empty or not?
What if parts of the element are positioned, transformed, animated, have
an SVG filter applied, constantly mutated via the DOM API, etc, etc?
On Wed, 2 May 2012, Aryeh Gregor wrote:
Currently the spec isn't clear about this for input, so I don't think
it needs to specify exactly for textarea or contenteditable either.
I strongly disagree. input and textarea are high-level constructs, so
it's fine for them to be defined by the UA's platform. But contenteditable
is a very low-level primitive. We can't just punt on how it interacts with
CSS; otherwise people will have no way to reliably make UIs with it.
On Wed, 2 May 2012, Alfonso Mart�nez de Lizarrondo wrote:
Recently I wrote such a plugin for CKEditor, it can be tested here:
http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html
I don't think that too many people request this feature, but that might
be simply because there are other bigger problems and they don't want to
waste the time with these details :-)
In my checks to see if the editor is empty I decided that empty means no
real content, only a paragraph or new line, and of course every browser
decided that clearing the content might mean a different default content
In the end this is the check that I'm using at the moment (I didn't
perform extensive tests, just enough to check that it seemed to work)
var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase();
if ( !value || value == 'br' || value == 'pnbsp;br/p' || value ==
'pbr/p' || value == 'pnbsp;/p' )
return true;
Now there's a problem we should fix. Having five different representations
of nothing seems like a terrible position for us to be in.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Allow empty string for input type=color
On Thu, 3 May 2012, Markus Ernst wrote: I apologize in case this has been discussed before - the list archive search seems to be broken right now, as it does not find any matches when searching for color. I just noticed a note in the spec of input type=color http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#color-state-%28type=color%29: Note: In this state, there is always a color picked, and there is no way to set the value to the empty string. If I understand the spec correctly, entering no value defaults to #00, thus the required attribute does not apply. What are the reasons for this? I am sure there were good reasons to specify it this way, anyway I don't see them right now. Not selected is actually very different from black. I see the following reasons for allowing the empty string: 1. An application might want to give the user the choice of not selecting a color. Not specifying a color is the easiest way to state that the default color should be used, be it black or other. 2. An application might want to force the user to make an explicit selection. It may not be able to distinguish whether black was explicitly selected, or the user forgot to specify a color. 3. Applications need to deal with the empty string anyway, as legacy browsers show a text field. On Thu, 3 May 2012, Anne van Kesteren wrote: Not selected is not something typically supported by native color pickers. On Fri, 4 May 2012, Shaun Moss wrote: The way things are done is not always the best way. Most colour pickers are used in instances where not selected would make no sense. However, as you're designing a widget for the web that may be used by billions of people in any number of unforeseen ways, flexibility is a virtue, and the option to clear the field would be an improvement. If you don't allow a not selected or null option, this would basically force all colour widgets to be required fields, which may not be what the form designer wants. To compare, some date pickers do not allow you to clear the field, but some do. For the web, it's a useful feature. On Thu, 3 May 2012, Ashley Sheridan wrote: Would the colour pickers allow the selection of the alpha channel at the time of choosing? If so, couldn't you allow a full transparent colour to be used where null couldn't? On Thu, 3 May 2012, Alfonso Mart�nez de Lizarrondo wrote: Being able to not select a color isn't so strange. Everyone is used to word processors, and they usually have an option to select the color for the text and background. And among those available colors there's an option to use the default text color or to use a transparent background/no color. While it's true that certain colour pickers do have a no colour option, it is generally the case that, as with range controls, there's no none option in the typical UI. I expect we will add support for this at a future time, just like we will likely add support for more detailed range controls (e.g. that have a min and a max slider). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Search-suggestions without scripting
On Mon, 7 May 2012, Bjartur Thorlacius wrote: On 5/5/12, Ian Hickson i...@hixie.ch wrote: Note that even in this space, though, it's not the end of the story. For example, Chrome does more than just list the search autocomplete results; it also loads the first suggestion in the background, and mixes in results from local history search, etc. Other browsers do similar mixing. While this works well for browser UI, where the browser can mix in all the various results together, when you are talking about a Web page you still end up needing script to do that. So having it declarative isn't necessarily a win. Mixing multiple sources, such as user history and site suggestions, and automatically performing actions upon them, such as prefetch and prerender, should be easier for the user agent to do if the necessary information to do so is declared, no? My point wasn't that the UA would want to add stuff, but that this kind of thing (an autocomplete widget, even one done entirely by and for the page, without the browser adding stuff) is in general more complicated than just here's a list of completion suggestions. It's here's five sources of data, let me rank them and figure out how to list them, or here's a bunch of options including a rich entry with graphics, or any number of other complicated things. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] instantiating display:none plugins
On Tue, 8 May 2012, Jonas Sicking wrote: On Tue, May 8, 2012 at 2:06 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Nov 2011, Robert O'Callahan wrote: One more thing. I added a hide and show plugin with flush test that sets the plugin to display:none, causes a layout flush (by requesting body.getBoundingClientRect()) and then sets the plugin back to display:inline. On Firefox, Chrome and Opera this restarts the plugin instance; on IE9 it doesn't. If you take out the flush, none of the browsers restart the plugin. I think this should just be considered a browser bug. We don't want to have to specify the timing of style and layout flushing. (We'll fix this in Firefox shortly.) I just did it as a task that is queued. (This means it doesn't cause anything to happen if an alert() fires, because per spec alert() blocks the event loop. This isn't consistent with the test cases you gave. Not sure what to do about that.) This creates a pretty racy situation. Plugin instantiation is often racy anyway, since you have to download the resource to work out that it needs a plugin. Consider a page which reacts to a state change by showing or hiding a bunch of UI by setting display:none on an element. If two of these state changes happen in response to a timers, the showing/hiding will sometimes cause the plugin to restart, sometimes not. If the two timers end up in the queue before any of them fire then the task to kill the plugin won't have time to run in between. If they end up slightly further apart it will cause the plugin to get restarted. For object, yeah. I suppose I could have the special case of the element obviously no longer having a plugin (e.g. it's now display:none) result in the plugin being killed sync with the event loop going back to step 1, but that's going to make the algorithm even more crazy. Are we sure we want that? For embed the situation is much simpler, and so it's indeed based on the event loop and not a queued task. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video preload implementation feedback
On Wed, 9 May 2012, Simon Pieters wrote: On Tue, 08 May 2012 18:59:29 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Aug 2011, Philip Jägenstedt wrote: This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. Images aren't required to load at all. Scripts aren't required to run at all. The window size is allowed to be any dimension at all. CSS isn't required to be supported at all. Users are allowed to apply arbitrary user style sheets. Users are allowed to interact with form controls by using the keyboard or the mouse or any other input device. All of these do break some pages. That CSS is optional and that users are allowed to apply user style sheets didn't stop you from specifying the Rendering section in great detail. Optional detail. UAs aren't required to follow that section. Making video behavior underdefined just because users should be able to disable video loading in preferences just means that in a few years the behavior of the market leader needs to be reverse engineered and implemented by everyone else. I do not understand how this particular feature could end up in that state any more than the other features I list above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should a textarea outside of a document be immutable?
On Mon, 14 May 2012, Mounir Lamouri wrote: According to the HTML specifications, a textarea is mutable if it is neither disabled nor has a readonly attribute specified. Which means that a textarea outside of a document is mutable. This is not the case for an input element. I was wondering why there is this difference in behavior here between those two elements. I believe both elements should be immutable when outside of a document. The requirement for input was the remnants of an attempt to define something better in the context of XBL2. I've dropped it. Elements that are not in the document, or indeed that are in a document without a browsing context, or are display:none, or children of an element that doesn't represent its contents (e.g. br, img, object in some cases, video, audio, etc), or scrolled off the screen, or overlapped by some other element, or any number of other cases, can't typically be edited. The spec does allow UAs to allow users to edit them in all these cases, but only requires it as a SHOULD; the inability for the user to reach the element at all in these cases is considered a reasonable reason to not implement the requirement in those cases. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, Jun 12, 2012 at 7:39 AM, Charlie Reis cr...@chromium.org wrote: On Mon, Jun 11, 2012 at 11:24 PM, Anne van Kesteren ann...@annevk.nlwrote: Having a rel attribute imply a target attribute value seems bad. Thus far they have been orthogonal. Maybe it should be a new target attribute value instead? I'm not opposed to that, and it does seem simpler. Something like target=_unrelated? Thanks for the suggestion. I've updated http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts with a second proposed solution for target=_unrelated (similar to target=_blank, but in an unrelated context). It works better for the window.open case as well. Any feedback on this revised approach? Thanks, Charlie
Re: [whatwg] Detecting eventListeners
On Fri, 25 May 2012, Xavier Ho wrote: We're working on a project that requires detection of registered event listeners. Our targets are old-style onclick attribute bindings, events registered via addEventListener (and the IE equivalent), and other custom event libraries such as jQuery's. As far as we can tell, there is no way to determine if an element has an eventListener attached to it, created via addEventListener. There is a sure way to remove an event (via removeEventListener), but we want to enter some code path if and only if an element has an event registered, without altering its eventListener. This is currently not possible. Many discussions about this topic has been raised in the past. This Stackoverflow answer has a good summary: http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist As far as the author could tell, this feature was never implemented due to a lack of a use-case. We have a use-case. What specifically is your use case? The main reason this isn't supported is that it breaks the event model: the idea of events is that listeners don't affect whether something is dispatched or not. You should be able to attach a no-op listener for every event type to event event target and there should be no noticeable effect. On Thu, 24 May 2012, Glenn Maynard wrote: On Thu, May 24, 2012 at 10:07 PM, Xavier Ho cont...@xavierho.com wrote: A very common use-case is to record a mouse click on a DOM element which may fire an event on the page. We want to capture clicks that actually triggered an event, does a HTTP request, and so on, but not meaningless clicks on an empty region. I don't see how enumerating event listeners would let you distinguish these cases. That said, there is no way of surely determining if a click is meaningful. We check if the DOM element clicked on is a button, a link (has href), has onclick attribute set, and so on. However, this will fail on sites that binds 'click' via 'addEventListener' on a strange element, like a span or a em tag. This will also fail if the event handler is up the node tree. Indeed. I often just set my mouse listeners on the Window object and check the target manually (since that allows me to detect when the mouse left the target unexpectedly too), and you wouldn't be able to catch that case by enumerating listeners. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 13, 2012 at 4:44 PM, Michal Zalewski lcam...@coredump.cxwrote:
Any feedback on this revised approach?
My vague concern is that the separation is a bit fuzzy, beyond saying
that window.opener will be null... if that's the only guaranteed
outcome, then maybe that should be spelled out more clearly? The
degree of separation between browsing contexts is intuitive in the
case of Chrome, given the underlying implementations, but will it be
the same for Internet Explorer or Firefox or Safari?
That's a fair point, since those browsers have a global namespace for
windows. You're right that the main change would be not setting
window.opener or returning a value from window.open, even though the
windows might find each other through other means in those browsers.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right? That may be unexpected.
The same goes the other way - the spec subtly implies that because
window.open('foo', '_unrelated') returns null, the opener will not be
able to mess with the opened window, but that's not guaranteed given
that the reference may be leaked by other means, right?
/mz
Correct. In that example, the new window could give itself a name, and the
opener would then be able to find it (in browsers with a global namespace
for windows).
I'm not sure how easy it would be to create a different namespace for the
unrelated window in other browsers, and I don't expect that to change. I
still think this proposal can be useful, though, especially for an unnamed
window trying to open an untrusted link.
It's worth noting that pages that don't want to be found already either
have to clear their name or use an unpredictable one, and that wouldn't
change here.
I can call this issue out more explicitly in the proposal if you'd prefer.
Charlie
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different ones, based on whatever
heuristics it uses for deciding whether it's spawned enough processes.
Let's assume that there is no Chrome-style process isolation, and that
this is only implemented as not giving the target=_unrelated document
the ability to traverse window.opener. If the document's opener lives
in an already-named window (perhaps unwittingly), it won't be
prevented from acquiring the handle via open('',
'name_of_that_window'), right?
The spec needs to require that this be prevented
-Boris
Re: [whatwg] communicating plugin state (primarily for click-to-play)
Turns out another Mozilla developer did add out-of-content UI for click-to-play to Firefox, I just didn't notice it because our current UI is as hard to notice as Chrome's (nearly impossible unless it's pointed out to you). My experimentation with it didn't turn up anything new or unexpected. After thinking about this more I'd like to withdraw my request to add a property to object/embed elements. It might make things a bit easier or more clear for web developers, but they can already make sites behave pretty well if they know what to do. Instead of adding something to the spec we can probably make do with best-practices recommendations for site changes. Thanks for the feedback. On Tue, Jun 12, 2012 at 4:24 PM, Peter Kasting pkast...@google.com wrote: On Tue, Jun 12, 2012 at 1:26 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: What about doing what popular plugin blockers do and offer the notification in the area the plugin was intended to be used? I was operating under the assumption the UA was already doing that. Hence why we're talking about non-user-visible plugins in the first place. PK
