Re: [whatwg] Details on window.open
On Tue, 18 Dec 2012, Boris Zbarsky wrote: On 12/18/12 3:53 PM, Ian Hickson wrote: Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. That's not web-compatible... I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? Gecko's current behavior is as follows: [...] I strongly suggest talking to all UA vendors about how their popup blockers actually worked. The Gecko setup used to be simpler, but we've had to add complications to it as we came across site compat issues... I've tried to spec something that's close to what you describe and what other vendors have described to me. It's better, but it's still not perfect; if there's some way in which it is inadequate, please don't hesitate to report it. I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. I think on desktop you're somewhat wrong (e.g. it's possible to get site compat bugs where you open a window at the wrong size and users can't get to content)... Can't they just resize the window or scroll it? What happens on UAs that don't have sized windows, like most implementations of browsers on phones? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On 7/15/13 4:44 PM, Ian Hickson wrote: I've tried to spec something that's close to what you describe and what other vendors have described to me. Thank you. I'll try to find time to review it, but I can't give you an ETA. :( Can't they just resize the window or scroll it? It depends. It's common to open these windows non-scrollable (which UAs usually obey) and unresizable (which they don't necessarily obey) What happens on UAs that don't have sized windows, like most implementations of browsers on phones? The pages are completely unusable. That describes a whole lot of pages... -Boris
Re: [whatwg] Details on window.open
On Mon, 15 Jul 2013, Boris Zbarsky wrote: On 7/15/13 4:44 PM, Ian Hickson wrote: Can't they just resize the window or scroll it? It depends. It's common to open these windows non-scrollable (which UAs usually obey) and unresizable (which they don't necessarily obey) Fair enough. What happens on UAs that don't have sized windows, like most implementations of browsers on phones? The pages are completely unusable. That describes a whole lot of pages... Seems like we should stop obeying making pages unscrollable. I haven't adjusted the spec to honour the details on window.open(), given the above. In particular, since some UAs can't honour them anyway, it seems wise for more UAs to just ignore them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On Sun, 7 Oct 2012, David Bruant wrote: I've been searching on the web for complete documentation about window.open and I have some unanswered questions. 1) what are the rules for popup blockers? Is every call to window.open blocked in modern browsers or are there exceptions? Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. (The spec also allows blocking in some other cases, and requires blocking in some sandbox cases, but those aren't popup-blocking-related.) I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. 3) Is what is returned a instance of Window or WindowProxy? By that I mean that if one browsing context A opens C and B window.open C too changing the URL (and reloading), is A supposed to have access to the new C or only the old browsing context? You can never get hold of a raw Window object, only WindowProxy objects. In your scenario, provided it's all same-origin, A will have an object that reflects that the browsing context has a new document loaded in it. (It's only one browsing context though.) 4) About step 4 of The rules for choosing a browsing context given a browsing context name [1]: If the given browsing context name is not |_blank| and there exists a browsing context whose name is the same as the given browsing context name, and the current browsing context is allowed to navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, What does related enough mean? That's up to the UA. How is it implemented in different browsers? It varies. Gecko, IIRC, thinks everything is related enough. Chrome probably limits it to same-process windows. then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related. What is the consistent manner in each implementation? I do not know. I hope that this doesn't matter for interop; if I'm wrong, let me know and we shall spec it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Details on window.open
On 12/18/12 3:53 PM, Ian Hickson wrote: Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. That's not web-compatible... I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? Gecko's current behavior is as follows: There are four possible states we can be in for popups: Allowed (allows popups), Controlled (allows popups, but only up to a global maximum number of popups opened from states other than Allowed), Abused (does not allow popups normally) and Overridden (does not allow popups normally). If a site is white-listed in preferences to allow popups, then for that site Controlled is treated as Allowed and Abused is treated as Controlled. The default state is Abused, I believe. During handling of user input (which is NOT the same thing as an event being trusted, iirc; in particular there is some timer involved after an actual user input event was handled during which we treat things as being user input, because of sites doing window.open() from timeouts set from onclick), the popup state is set as follows: click: Allowed if click is in the popup-allowed whitelist select, change, input, keypress, keyup, keydown, mouseup, mousedown, dblclick, error, submit, reset: Controlled if the event name is in the popup-allowed whitelist The default value of the whitelist is change click dblclick mouseup reset submit, but can be modified by the user. Furthermore, certain things propagate the popup state that was active at a previous point in time. Specifically: 1) Loading a javascript: URI will record the state that was active when the load started, and temporarily set that state during the async execution of the script. So if your click handler sets a javascript: URI that does window.open(), that will work. 2) Calling click() on an input type=file will record the active popup state and test it when the task that would actually open the file dialog runs. This is more or less an implementation detail, looks like; it's equivalent to just checking the state in click(), as long as you ignore the exact firing time of popup-blocked events. 3) Submitting a form will record the popup state at the time the submission started. When the asynchronous part of the submission happens (which is when a window would get opened if the form has an @target), this popup state is used to decide whether to allow the window to open. I think this might be it, except for some code around plug-ins that I can't make sense of right now. I strongly suggest talking to all UA vendors about how their popup blockers actually worked. The Gecko setup used to be simpler, but we've had to add complications to it as we came across site compat issues... I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. I think on desktop you're somewhat wrong (e.g. it's possible to get site compat bugs where you open a window at the wrong size and users can't get to content)... Most things other than the size bit can probably be ignored in that feature string, though. -Boris
Re: [whatwg] Details on window.open
On 10/7/12 6:32 AM, David Bruant wrote: 1) what are the rules for popup blockers? Browser-dependent. Gecko uses a combination of several heuristics to block popups, based on what sort of platform event are being processed when the window.open call happens, how many popups are already open, which exact site the call is on, etc. Is every call to window.open blocked in modern browsers or are there exceptions? Well, onclick=window.open() usually works. It might be good to come up with a cross-browser list of cases like that that content actually depends on. 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? The latter, especially across different kinds of devices and different browser UIs. If you limit to desktop browsers, there's some agreement on what the width and height of the resulting window should be... assuming it's actually a window that opens, not a tab. 3) Is what is returned a instance of Window or WindowProxy? Web page script never has direct access to a Window. Whenever you have an object reference, it's always a WindowProxy. -Boris
[whatwg] Details on window.open
Hi, I've been searching on the web for complete documentation about window.open and I have some unanswered questions. 1) what are the rules for popup blockers? Is every call to window.open blocked in modern browsers or are there exceptions? 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? 3) Is what is returned a instance of Window or WindowProxy? By that I mean that if one browsing context A opens C and B window.open C too changing the URL (and reloading), is A supposed to have access to the new C or only the old browsing context? 4) About step 4 of The rules for choosing a browsing context given a browsing context name [1]: If the given browsing context name is not |_blank| and there exists a browsing context whose name http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-name is the same as the given browsing context name, and the current browsing context is allowed to navigate http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#allowed-to-navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, What does related enough mean? How is it implemented in different browsers? then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related. What is the consistent manner in each implementation? David [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
Re: [whatwg] Details on window.open
On Sun, Oct 7, 2012 at 3:32 AM, David Bruant bruan...@gmail.com wrote: I've been searching on the web for complete documentation about window.open and I have some unanswered questions. 1) what are the rules for popup blockers? Is every call to window.open blocked in modern browsers or are there exceptions? I don't think the spec requires an specific behavior. Generally speaking, user agents can be configured as to which sorts of popups they block. Most user agents block popup that were not initiated during a user gesture. 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? 3) Is what is returned a instance of Window or WindowProxy? WindowProxy. The web platform never returns a direct reference to a Window object. By that I mean that if one browsing context A opens C and B window.open C too changing the URL (and reloading), is A supposed to have access to the new C or only the old browsing context? The new C. 4) About step 4 of The rules for choosing a browsing context given a browsing context name [1]: If the given browsing context name is not |_blank| and there exists a browsing context whose name http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context-name is the same as the given browsing context name, and the current browsing context is allowed to navigate http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#allowed-to-navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, What does related enough mean? That varies by implementation. How is it implemented in different browsers? That's a long, complicated topic. Some user agents track units of related browsing contexts. For example, Chrome ensures that units of related browsing contexts are not split across process boundaries. In Chrome, the search of related enough browser contexts stops at process boundaries. then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related. What is the consistent manner in each implementation? You might need to run some experiments to answer this question for yourself. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
