Missing navigation controls on window.open

[Stephen Chenney]

Bug 82522 was brought to my attention and the response to all the user complaining has been, to put it mildly, underwhelming.

At issue is the lack of navigation, menu and editable URL on a window opened with window.open from js.

Could someone with a clue as to why Chrome behaves this way please, at a minimum, respond to the bug report? If it's a bug it would be really nice if someone fixed it as we seem to behave differently to every other browser.

There's some discussion here, http://stackoverflow.com/questions/2572333/google-chrome-window-open-workaround, but that seems to be related to how to get a window at all, instead of a tab, and doesn't address the lack of controls. The behavior described there does seem to be security related; we don't want a page to be able to open popup windows without some explicit user action. But it doesn't explain why, once the window is open, the controls are missing.

Stephen.

[Adam Barth]

We seem to have all the code for parsing the toolbar window feature and the state seems to be plumbed all the way to make ChromeClientImpl::getNavigationPolicy() return NavigationPolicyNewForegroundTab.  My guess is there's just a bug somewhere.  Given you you seem excited about this bug, my guess is that you could track it down by following the trail from WindowFeatures to ChromeClientImpl::getNavigationPolicy() in a debugger to see where we go off the rails.

Adam

[Stephen Chenney]

On Fri, Jun 27, 2014 at 12:46 PM, Adam Barth <aba...@google.com> wrote:

We seem to have all the code for parsing the toolbar window feature and the state seems to be plumbed all the way to make ChromeClientImpl::getNavigationPolicy() return NavigationPolicyNewForegroundTab.  My guess is there's just a bug somewhere.  Given you you seem excited about this bug, my guess is that you could track it down by following the trail from WindowFeatures to ChromeClientImpl::getNavigationPolicy() in a debugger to see where we go off the rails.

Adam

Turns out that we follow IE behavior and set all other window features to false if any feature is set true in the features string. Then, if any window feature is not true, we set the window to open as a popup. The code that opens the window does not receive the features structure so always creates a minimal popup-style window.

The problem is really in the code that opens the window in that it never receives and can't act on the window features, although I am pretty sure we can't even create a window that has a subset of the window chrome - we would have to create a full browser window with a tab inside it containing the referenced content.

I'm going to put up a patch that ignores the features and always causes us to open a new tab in the current window, which is better than the current solution. The alternative is to always open a new window with a new tab if any of the features are specified, but I am less sure that's a good idea.

Stephen.

[PhistucK]

Unless I am misunderstanding, your patch idea does not look right - how would you create a real popup then?

If anyone works on this, they should take a look at crbug.com/157354 as well. I think it is a superset of this issue.

Damn, I tried to take a look, but I got totally lost. How come codesearch shows that some code is calling a function with six parameters and when you click on the name of the function in codesearch, it shows a function with eight parameters?...

Well, this is probably some C++ thing I do not know...

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Stuart Morgan]

On Fri, Jun 27, 2014 at 3:04 PM, PhistucK <phis...@gmail.com> wrote:

How come codesearch shows that some code is calling a function with six parameters and when you click on the name of the function in codesearch, it shows a function with eight parameters?...

Default parameter values:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/CreateWindow.h&sq=package:chromium&type=cs&l=40

-Stuart 

[PhistucK]

I figured it was something like that, but I assumed default parameters would also show in the implementation file and not only in the header file. But that makes sense!

Thank you for answering my stupid question. :)

☆PhistucK

[Darin Fisher]

If I'm understanding the issue correctly, it was an intention choice to simplify things here. Chrome has an option in the popup window menu to "show as tab" which gives you back all of the standard controls.

-Darin

[Peter Kasting]

On Sat, Jun 28, 2014 at 2:18 PM, Darin Fisher <da...@chromium.org> wrote:

If I'm understanding the issue correctly, it was an intention choice to simplify things here. Chrome has an option in the popup window menu to "show as tab" which gives you back all of the standard controls.

This.  We allow you to convert popup windows into full-fledged tabbed windows as needed, but don't do it automatically.

I'm not opposed to a behavior where, in general, we open window.open() pages as new tabs in the current window instead of popup windows, but authors probably have to be able to do both, and not being familiar with the various permutations of window.open, I can't tell you what the heuristics should be to pick one over the other.  (Personally, I would be happy with a world where all such windows _always_ opened in new tabs, and indeed that's how I used to configure Firefox... but I bet that breaks some pages and might confuse users if it were the default behavior.  Blink experts, feel free to tell me I'm wrong and this is actually a good idea.)

It seems like today I see pages doing both of these behaviors, so I imagine we already have some code along these lines.

The only place we really don't want to be is where we allow some window features (nav controls, editable URLs) but not others (a tabstrip), because the downsides are greater than the upsides.  (Even more confusing to users than our current world, more code complexity to maintain.)

PK

[Darin Fisher]

On Sat, Jun 28, 2014 at 3:59 PM, Peter Kasting <pkas...@google.com> wrote:

On Sat, Jun 28, 2014 at 2:18 PM, Darin Fisher <da...@chromium.org> wrote:

If I'm understanding the issue correctly, it was an intention choice to simplify things here. Chrome has an option in the popup window menu to "show as tab" which gives you back all of the standard controls.

This.  We allow you to convert popup windows into full-fledged tabbed windows as needed, but don't do it automatically.

I'm not opposed to a behavior where, in general, we open window.open() pages as new tabs in the current window instead of popup windows, but authors probably have to be able to do both, and not being familiar with the various permutations of window.open, I can't tell you what the heuristics should be to pick one over the other.  (Personally, I would be happy with a world where all such windows _always_ opened in new tabs, and indeed that's how I used to configure Firefox... but I bet that breaks some pages and might confuse users if it were the default behavior.  Blink experts, feel free to tell me I'm wrong and this is actually a good idea.)

Right. Some popups are intended to float over top an existing window. We use a very simple heuristic: if window.open is passed options that hide some element of the window frame, then we treat it as a popup. Otherwise, we treat it as a new tab.

 

It seems like today I see pages doing both of these behaviors, so I imagine we already have some code along these lines.

The only place we really don't want to be is where we allow some window features (nav controls, editable URLs) but not others (a tabstrip), because the downsides are greater than the upsides.  (Even more confusing to users than our current world, more code complexity to maintain.)

+1

-Darin

[PhistucK]

I think the heuristic is a bit too aggressive.

The code should ignore any feature that the window does not have, or features that cannot be disable, like statusbar=1 (or is it status=1?), menubar=1 and location=1 and treat the rest accordingly. Currently, if you do not specify all (but not none) of the features, you get a popup - which seems counter intuitive to me (and others, if you look at the various issues).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Stephen Chenney]

Thanks for the feedback. I thought about this some more over the weekend and come to the conclusion that our real problem is an outdated spec. Turns out others have noticed this too and updated the spec. From http://www.w3.org/TR/html5/browsers.html#dom-open:

"The third argument, features, has no defined effect and is mentioned for historical reasons only. User agents may interpret this argument as instructions to set the size and position of the browsing context, but are encouraged to instead ignore the argument entirely."

So according to the spec we simply need to create an "auxiliary browsing context" and we're free to choose whether that is a new tab in the current window or a new window with a single tab.

Opening a new tab is easy to code - we just stop processing the features string.

Opening a new window with a tab is more of a change (it will change the existing behavior for the no-features case). I am not willing to implement that myself because the code that creates a new window needs profile information and I'm not confident I can do it without breaking security/privacy in some way. But an expert could do it.

I propose we switch to the new tab behavior on widow.open because (a) it's easier to pop a tab out into a window rather than the reverse with a window that has no controls and (b) it disables only something that is already considered broken by some of our users (and is incompatible with other browsers).

But first I will add a UseCounter to try to figure out how frequently people use the features string in window.open.

Doing it right probably requires a user-level setting of a default new tab or new window behavior, with Ctrl-clink or other UI to offer per-click choice, as the spec does not offer any way to choose from script. That's for the UI team to decide.

Stephen.

[Mike Pinkerton]

Note that Mac doesn't support the context-click menu on the title bar, so there is no way to do this on Mac. I think i WONTFIXd that bug 3 or 4 years ago because it was an undiscoverable action that doesn't fit with the platform. Now typing this, I see you can do this in the Finder to adjust toolbar contents/appearance, so maybe we should re-evaluate the decision and support it, if that's how we want to handle this for realz.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
Mike Pinkerton
Mac Weenie
pink...@google.com

[Peter Kasting]

On Mon, Jun 30, 2014 at 8:11 AM, Stephen Chenney <sche...@chromium.org> wrote:

Opening a new window with a tab is more of a change (it will change the existing behavior for the no-features case). I am not willing to implement that myself because the code that creates a new window needs profile information and I'm not confident I can do it without breaking security/privacy in some way. But an expert could do it.

We shouldn't move to a world where we sometimes open new windows with one tab in them for window.open.  The two behaviors we have today -- a special popup window, and a regular tab in the current window -- are the right two.

I propose we switch to the new tab behavior on widow.open because (a) it's easier to pop a tab out into a window rather than the reverse with a window that has no controls and (b) it disables only something that is already considered broken by some of our users (and is incompatible with other browsers).

Like I said, I'm personally fine with a world where we always did this, but I doubt we can go there (and Darin's reply to me seems to confirm this).

Doing it right probably requires a user-level setting of a default new tab or new window behavior, with Ctrl-clink or other UI to offer per-click choice, as the spec does not offer any way to choose from script. That's for the UI team to decide.

We wouldn't add a preference for such a thing.

PK 

[Stephen Chenney]

I've got patches up for the UseCounter. That will tell us the proportion of window.open that use the features string which is a proxy for popup a new window rather than a new tab. There is a major caveat in that corporate sites will bias the statistics (a la showModalDialog) so we'll have to be careful what we infer. That is particularly the case because we are currently suggesting window.open as the alternative for showModalDialog.

On Mon, Jun 30, 2014 at 2:50 PM, Peter Kasting <pkas...@google.com> wrote:

On Mon, Jun 30, 2014 at 8:11 AM, Stephen Chenney <sche...@chromium.org> wrote:

Opening a new window with a tab is more of a change (it will change the existing behavior for the no-features case). I am not willing to implement that myself because the code that creates a new window needs profile information and I'm not confident I can do it without breaking security/privacy in some way. But an expert could do it.

We shouldn't move to a world where we sometimes open new windows with one tab in them for window.open.  The two behaviors we have today -- a special popup window, and a regular tab in the current window -- are the right two.

Unfortunately the new spec, as I understand it, requires us choosing one or the other (or ignore the spec). It seems that the <dialog> element is explicitly intended to give us the popup window functionality, leaving window.open to be a tab-opening method.

[Darin Fisher]

On Mon, Jun 30, 2014 at 12:47 PM, Stephen Chenney <sche...@chromium.org> wrote:

I've got patches up for the UseCounter. That will tell us the proportion of window.open that use the features string which is a proxy for popup a new window rather than a new tab. There is a major caveat in that corporate sites will bias the statistics (a la showModalDialog) so we'll have to be careful what we infer. That is particularly the case because we are currently suggesting window.open as the alternative for showModalDialog.

I'm not sure what UseCounter will really show us. It is hard to tell when a site expects a pop-up to overlay with the current window rather than be a separate full-window experience. Sometimes a popup is something shown to the user in context with what they are currently doing. Sometimes developers expect to have control over the shape and positioning of the pop-up. (I can think of some chrome experiments that depended on this.) Sometimes it is really odd to size the contents of a pop-up to the full width and height of a browser window. These are UX concerns that seem really hard to measure.

Considering Gmail, which uses pop-ups to implement the pop-out feature for emails and chats, it seems like a full window pop-out may not always be what you want. A chat window expanded to the full width of your browser window can be really odd looking for example.

 

On Mon, Jun 30, 2014 at 2:50 PM, Peter Kasting <pkas...@google.com> wrote:

On Mon, Jun 30, 2014 at 8:11 AM, Stephen Chenney <sche...@chromium.org> wrote:

Opening a new window with a tab is more of a change (it will change the existing behavior for the no-features case). I am not willing to implement that myself because the code that creates a new window needs profile information and I'm not confident I can do it without breaking security/privacy in some way. But an expert could do it.

We shouldn't move to a world where we sometimes open new windows with one tab in them for window.open.  The two behaviors we have today -- a special popup window, and a regular tab in the current window -- are the right two.

Unfortunately the new spec, as I understand it, requires us choosing one or the other (or ignore the spec). It seems that the <dialog> element is explicitly intended to give us the popup window functionality, leaving window.open to be a tab-opening method.

There is historically a line in the sand between what is specified and what is left up to the user agent. Maybe the spec is being overly prescriptive about a UA concern? Also, <dialog> is not really a replacement for pop-ups. It does not create a new overlapped window. The <dialog> is scoped (clipped) to the parent window, right?

-Darin

[Matt Falkenhagen]

There is historically a line in the sand between what is specified and what is left up to the user agent. Maybe the spec is being overly prescriptive about a UA concern? Also, <dialog> is not really a replacement for pop-ups. It does not create a new overlapped window. The <dialog> is scoped (clipped) to the parent window, right?

This is correct, <dialog> is clipped to its containing window. It doesn't pop out of the window/iframe.

[Chris Harrelson]

On Mon, Jun 30, 2014 at 9:08 AM, Mike Pinkerton <pink...@chromium.org> wrote:

Note that Mac doesn't support the context-click menu on the title bar, so there is no way to do this on Mac. I think i WONTFIXd that bug 3 or 4 years ago because it was an undiscoverable action that doesn't fit with the platform. Now typing this, I see you can do this in the Finder to adjust toolbar contents/appearance, so maybe we should re-evaluate the decision and support it, if that's how we want to handle this for realz.

This is IMO a big problem. There is no way to turn a popup window into a regular tab on Mac, and as far as I can see, on Linux either. This means that users are not in control of what happens in that tab like they are in regular tabs. e.g. you can't use extensions (*), view source if the developer has overriden the context menu on the page, reload...

(*)  WatchESPN is one example where, as far as I can tell, you can't use Chromecast for videos for this reason.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Mike Pinkerton]

If we agree that the status quo is how we want to solve this issue, please file a new bug for Mac so we can bring support in line. I'm not sure we've agreed on that yet, though.

[Eric U]

On Linux: right-click on title bar, select "Show as tab". Works for
me in Gnome; your window manager may, of course, vary.

[Simon Pieters]

On Mon, 30 Jun 2014 17:11:54 +0200, Stephen Chenney
<sche...@chromium.org> wrote:

> Thanks for the feedback. I thought about this some more over the weekend
> and come to the conclusion that our real problem is an outdated spec.
> Turns
> out others have noticed this too and updated the spec. From
> http://www.w3.org/TR/html5/browsers.html#dom-open:

Please don't look at TR/. Use http://whatwg.org/html

> "The third argument, features, has no defined effect and is mentioned for
> historical reasons only. User agents may interpret this argument as
> instructions to set the size and position of the browsing context, but
> are
> encouraged to instead ignore the argument entirely."
>
> So according to the spec we simply need to create an "auxiliary browsing
> context" and we're free to choose whether that is a new tab in the
> current
> window or a new window with a single tab.

I have tried to specify parsing of the features argument in
http://dev.w3.org/csswg/cssom-view/#the-features-argument-to-the-open()-method
although it's probably not compatible enough yet. I'm also happy to drop
it altogether if browsers are willing to ignore the argument like the HTML
spec suggests.

Also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25709

--
Simon Pieters
Opera Software

[Stephen Chenney]

Thanks Simon. Based on all the developer complaints about dropping their control over window vs. tab vs. navigation controls etc, my sense is that we would satisfy developers with just 3 context type options plus optional position/size:

- non-navigatable popup

- full window (as if you opened a new window from the browser menu)

- new tab (as if you did new tab on the browser menu)

I think this largely addresses the concerns people have raised on this thread. I have no idea how other browser vendors would react, but it does seem that each browser supports contexts of the suggested type.

Cheers,

Stephen.

[robb...@gmail.com]

This is exactly right, if you gave those 3 context type options it would satisfy all the developer complaints.