Borja Salguero [:borjasalguero] Reporter
	Description • 9 years ago

If we open an URL with <title> (or setting it through document.title = ...) has no effect in the header.

EXPECTED:
The title must be in the header of the dialog/window opened.

	Borja Salguero [:borjasalguero] Reporter
	Comment 1 • 9 years ago

Gregor, could you help us with this? Thanks!

	Gregor Wagner [:gwagner]
	Comment 2 • 9 years ago

Is this a regression? If so, do you have a small test case so we can find out a regression window?

	Alberto Pastor [:albertopq] Assignee
	Comment 3 • 9 years ago

I think this is a 'regression' of bug 1168961. We should probably still use the document.title on window.open. Ben, what do you think?

	Ben Francis [:benfrancis]
	Comment 4 • 9 years ago

Borja, out of interest what is the use case for this? What happens if you execute the same code in a browser window instead of an app window?

As we're moving to support multiple windows per app my ideal would be that window.open in an app wouldn't open a weird overlay window, but would just open another app window (windows will eventually be grouped by app in the task manager). Would that make sense in this case, or is this some kind of dialog window where you want it to be a child window? What arguments are you passing to window.open?

Is this an Open Web App or a Firefox App using the New Gaia Architecture? I expect we will support multiple windows per app for W3C web apps in 2.5, but I'm not sure whether we'll support multiple windows for Firefox Apps.

In the meantime we may need a patch to keep the old behaviour for overlay windows.

	Maria Angeles Oteo (:oteo)
	Comment 5 • 9 years ago

(In reply to Gregor Wagner [:gwagner] from comment #2)
> Is this a regression? If so, do you have a small test case so we can find
> out a regression window?

Adding one possible STR so QA team can track and verify this issue when it can be fixed.

1. Open Contacts application and create a contact with a telephone number (e.g Maria and 6666)
2. Create a new contact with the same telephone number (e.g Angeles and 6666) so matching view is shown.

Actual Result: In the Contacts matching view the title is wrong. See attached screenshot
Expected Result: In the Contacts matching view the title should be "Duplicates found"

	Borja Salguero [:borjasalguero] Reporter
	Comment 6 • 9 years ago

Hi Ben!
With NGA we are moving every view to a different HTML, and we are going to emulate the navigation in every case with the right approach.
In the case of the navigation between list, detail, settings... we are going to navigate as the web does, using <a> tags and changing the URL (as simple as it seems!).
In the cases of 'importing', 'exporting' and 'matching' a set of contacts, however, we were using an <iframe> added into the main index.html, and some .css to 'emulate' a window.open... (same transition, same UI...). This is probably because tech. debt we had in old versions of the OS, but currently there is no reason to use this <iframe> approach, so we are moving to 'window.open' (we need to keep this model based on UX requirements).

As part of the standard, a window opened by 'window.open' should use the <title> and update the header of the tab consequently (as expected in the browser). However, this is not working right now due to the regression we found.

For testing this you can follow the STR described by Maria Angeles in the former comment.

I hope it helps!

	Alberto Pastor [:albertopq] Assignee
	Comment 7 • 9 years ago

Hi Borja!

Just out of curiosity, what's the reason we cannot use an <a> navigation when importing/exporting/matching? Is that because of the animation?

Thanks!

	Ben Francis [:benfrancis]
	Comment 8 • 9 years ago

> As part of the standard, a window opened by 'window.open' should use the <title> and update the header of the tab consequently (as expected in the browser). However, this is not working right now due to the regression we found.

I don't think there's any standard which specifies this, how a particular user agent displays a window is part of its UI design. For exaxmple, Safari (desktop and mobile) will display the hostname, which here you're describing as a bug. I'm fine with making these popup windows use the title from the <title> element as was the previous behaviour as a short term fix, but I'm just trying to figure out what the long term design should be.

Currently in Firefox OS window.open('http://google.com') will open an overlay window and window.open('http://google.com', '_blank') will open a new browser window, that definitely isn't standard. If you call window.open('http://google.com') in Firefox or Chrome (on both desktop and mobile) it will just open another browser tab, and it will do the same thing if you specify target=_blank.

We should make the behaviour of browser windows and app windows consistent and the default behaviour for window.open() should be to open another window. It may be that there is a use case for these special "dialog" overlay windows, using a special argument to window.open() like the (technically non-standard) "dialog" feature https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Window_functionality_features but I don't think that should be the default behaviour in the long term. The current overlay windows were a workaround for the artificial "one window per app" restriction we've so far had in Firefox OS.

I have a page which is helpful for testing these things here http://people.mozilla.org/~bfrancis/hyperlink/

Anyway, let's roll a patch that does what you ask for, but be aware that this may change in the future and we may need to change your window.open() calls. I will file follow-up bugs for all of that though.

	Borja Salguero [:borjasalguero] Reporter
	Comment 9 • 9 years ago

(In reply to Alberto Pastor [:albertopq] from comment #7)
> Hi Borja!
> 
> Just out of curiosity, what's the reason we cannot use an <a> navigation
> when importing/exporting/matching? Is that because of the animation?
> 
> Thanks!

In the case of importing/exporting/matching we are using the same approach that you can find when logging with 'Persona' in Bugzilla (because for importing sometimes you must be prompted with the Google/Outlook login). You are prompted with a dialog with a title, and once you complete the form you are back into bugzilla logged with your account.

This was a UX requirement, and we are keeping the approach here, so that's why we are using window.open instead of <iframe>.

	Borja Salguero [:borjasalguero] Reporter
	Comment 10 • 9 years ago

(In reply to Ben Francis [:benfrancis] from comment #8)
> > As part of the standard, a window opened by 'window.open' should use the <title> and update the header of the tab consequently (as expected in the browser). However, this is not working right now due to the regression we found.
> 
> I don't think there's any standard which specifies this, how a particular
> user agent displays a window is part of its UI design. For exaxmple, Safari
> (desktop and mobile) will display the hostname, which here you're describing
> as a bug. I'm fine with making these popup windows use the title from the
> <title> element as was the previous behaviour as a short term fix, but I'm
> just trying to figure out what the long term design should be.

When I meant 'standard' I was referring to the Firefox Desktop one :). After reviewing the code of the old <iframe> approach seems that there was a huge effort to emulate this 'window.open' behaviour, and it seems that it's based on the consistency between Desktop & FirefoxOS. If you try the log in with Persona in Bugzilla you will see the same pattern that UX required here.

IMHO I would recover this behaviour by now (due to it's affecting NGA user experience), but I agree that this is something we should discuss with UX in a different bug and use the same approach (with the <title> or any other specification) for both Destkop & FirefoxOS.

	Alberto Pastor [:albertopq] Assignee
	Comment 11 • 9 years ago

(In reply to Borja Salguero [:borjasalguero] from comment #9)
> (In reply to Alberto Pastor [:albertopq] from comment #7)
> > Hi Borja!
> > 
> > Just out of curiosity, what's the reason we cannot use an <a> navigation
> > when importing/exporting/matching? Is that because of the animation?
> > 
> > Thanks!
> 
> In the case of importing/exporting/matching we are using the same approach
> that you can find when logging with 'Persona' in Bugzilla (because for
> importing sometimes you must be prompted with the Google/Outlook login). You
> are prompted with a dialog with a title, and once you complete the form you
> are back into bugzilla logged with your account.
> 
> This was a UX requirement, and we are keeping the approach here, so that's
> why we are using window.open instead of <iframe>.

Mhm, I can understand this pattern when trying to log in into another domain (Oauth like), and we should consider this use case for the window changes, but I think in some other cases (duplicated contacts, for example), the window.open is just used for the animation (which we can solve in many other ways).

Thanks for the explanation!

	Gregor Wagner [:gwagner]
	Comment 12 • 9 years ago

Visual regression

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 14 • 9 years ago

Not a regression per comment 3.

Alberto, do you know the action item of this bug? Are we still debating the proper behavior of window management?

	Alberto Pastor [:albertopq] Assignee
	Comment 15 • 9 years ago

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #14)
> Not a regression per comment 3.
> 
> Alberto, do you know the action item of this bug? Are we still debating the
> proper behavior of window management?

I'm not sure what next steps are here. I don't see any reason for using a window.open (may be I'm missing something) in this use case, so I would try to fix this by using a different iframe and animating it as a window.open. If that's not feasible given the timeframe we have, then probably we need to do a short term fix for keeping the title in popups. Francisco, what do you think?

	Francisco Jordano [:arcturus] [:francisco]
	Comment 16 • 9 years ago

TBH, doing an iframe or doing a window.open should not be the debate on how we do the apps, as both mechanisms happen in the web, why we should not use them?

A window.open, not showing the |document.title| (if exists), is an error.

	Alberto Pastor [:albertopq] Assignee
	Comment 17 • 9 years ago

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #16)
> TBH, doing an iframe or doing a window.open should not be the debate on how
> we do the apps, as both mechanisms happen in the web, why we should not use
> them?

Ben: "I don't think there's any standard which specifies this, how a particular user agent displays a window is part of its UI design. For exaxmple, Safari (desktop and mobile) will display the hostname, which here you're describing as a bug."

You are right that both options are used in the web, but the Popup opens a new window, which is not what we are currently doing in this case. I'm not against using them, but expecting that a window.open will open a new window in the same context of the app is not what currently happens in the web.

> 
> A window.open, not showing the |document.title| (if exists), is an error.

We are not using document.title in any (not only window.open) window right now. App (WebApp) name or hostname are being shown at the moment. Do you mean that we need a special case for window.open inside apps, or that we need to show the title in all the windows?

The reason I insist on the iframe is because I think we are using a window.open just because of the animation (and I'm probably wrong). Why is this screen different than any other in the Contacts app?

	Francisco Jordano [:arcturus] [:francisco]
	Comment 18 • 9 years ago

(In reply to Alberto Pastor [:albertopq] from comment #17)
> 
> We are not using document.title in any (not only window.open) window right
> now. App (WebApp) name or hostname are being shown at the moment. Do you
> mean that we need a special case for window.open inside apps, or that we
> need to show the title in all the windows?
> 
> The reason I insist on the iframe is because I think we are using a
> window.open just because of the animation (and I'm probably wrong). Why is
> this screen different than any other in the Contacts app?

Thanks for the appointment. Seems to me that we have different behavior in FxOS and Firefox desktop.

For example, go to this page: http://rip747.github.io/popupwindow/

Check with both firefox desktop and firefox os the different popups, specially the case 'Same Window > Example 2'

You'll see how for a popup the document title is used as title in the window, same as it's used as title in the tabs.

Is there any reason that I'm not seeing for having this divergence?

	Alberto Pastor [:albertopq] Assignee
	Comment 19 • 9 years ago

Don't get me wrong, I'm happy to add back the title if that's the spec, I was just pointing that relying on the title as the Header of the content (not the info inside the chrome) doesn't seem right to me. Look at the W3C definition:

"Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip"" [1]

As I said, happy to display the title back, but if we really want to make sure that an specific header is displayed, it should be inside the content and not relying on the chrome. That said, is just my opinion so I might be wrong.

[1] http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-title

	Francisco Jordano [:arcturus] [:francisco]
	Comment 20 • 9 years ago

Don't take me wrong either, ;), and I totally agree that we should follow standards.

I think we got to a miss understanding, I was talking about the title element, not the title attribute, which I agree that could be used for tooltips, but the title dom element, following the same spec, we have the following for the title element:

For reasons of accessibility, user agents must always make the content of the TITLE element available to users (including TITLE elements that occur in frames). The mechanism for doing so depends on the user agent (e.g., as a caption, spoken). [1]

[1] http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#edef-TITLE


If you open your dev tools in this page and perform:

window.open('https://bugzilla.mozilla.org/show_bug.cgi?id=1188350', '', 'dialog')

You will see how a new window is open, no tabs, and the title of that window is the content of the title element.

Taking a look to mdn:

https://developer.mozilla.org/en-US/docs/Web/API/Window/open

and the 'dialog' option, we can see we implement that in desktop. Also not just with dialog, but with anything that makes the browser open a new window (not a tab). Is the case of using width and height on the attributes, or use _target=blank. It creates a new window that the title coming from the title element.

	Alberto Pastor [:albertopq] Assignee
	Comment 22 • 9 years ago

Comment on attachment 8671426 [details]
[gaia] albertopq:1188350-title-window-open > mozilla-b2g:master

Etienne, could you please take a look? Thanks!

	Etienne Segonzac (:etienne)
	Comment 23 • 9 years ago

Comment on attachment 8671426 [details]
[gaia] albertopq:1188350-title-window-open > mozilla-b2g:master

Looking good!

	Alberto Pastor [:albertopq] Assignee
	Comment 24 • 9 years ago

master: https://github.com/mozilla-b2g/gaia/commit/a068470f78d2c6038e7cde2027b12330b5d7696b

	Lance（leave from Mozilla）
	Comment 25 • 9 years ago

This bug has been verified as "pass" on the latest build of Flame KK 2.5 and Aries KK 2.5 by the STR in comment5.

Actual results: In the Contacts matching view, the title is shown correctly (i.e. "Duplicates found").
See attachment: Flame KK v2.5.3GP
Reproduce rate: 0/10

Device: Flame KK v2.5 (Pass)
Build ID               20151022150207
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/76bd0c01d72e64ca4f261ffdb2652a91f961e930
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151022.185000
Firmware Date          Thu Oct 22 18:50:13 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK v2.5 (Pass)
Build ID               20151023005002
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1f03a14106e59280761ac53904340f389674337f
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151023.001128
Firmware Date          Fri Oct 23 00:11:35 UTC 2015
Bootloader             s1