Closed
Bug 1188350
Opened 9 years ago
Closed 9 years ago
When opening a URL with window.open, the title is not set properly
Categories
(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect, P3)
Firefox OS Graveyard
Gaia::System::Browser Chrome
ARM
Gonk (Firefox OS)
Tracking
(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)
VERIFIED
FIXED
blocking-b2g | 2.5+ |
Tracking | Status | |
---|---|---|
b2g-v2.2 | --- | unaffected |
b2g-master | --- | verified |
People
(Reporter: borjasalguero, Assigned: apastor)
References
Details
(Whiteboard: [systemsfe])
Attachments
(3 files)
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.
Reporter | ||
Comment 1•9 years ago
|
||
Gregor, could you help us with this? Thanks!
Flags: needinfo?(anygregor)
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?
Flags: needinfo?(anygregor)
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?
Flags: needinfo?(bfrancis)
Updated•9 years ago
|
Whiteboard: [systemsfe]
Updated•9 years ago
|
blocking-b2g: --- → 2.5+
Keywords: regression
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.
Flags: needinfo?(bfrancis) → needinfo?(borja.bugzilla)
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"
Updated•9 years ago
|
status-b2g-v2.2:
--- → unaffected
status-b2g-master:
--- → affected
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!
Flags: needinfo?(borja.bugzilla)
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!
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.
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>.
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.
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!
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?
Flags: needinfo?(apastor)
Keywords: regression
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?
Flags: needinfo?(apastor) → needinfo?(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.
Flags: needinfo?(francisco)
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?
Flags: needinfo?(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?
Flags: needinfo?(francisco) → needinfo?(apastor)
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
Flags: needinfo?(apastor)
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.
Updated•9 years ago
|
Component: Gaia::System::Window Mgmt → Gaia::System::Browser Chrome
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → apastor
Comment 21•9 years ago
|
||
Assignee | ||
Comment 22•9 years ago
|
||
Comment on attachment 8671426 [details] [review] [gaia] albertopq:1188350-title-window-open > mozilla-b2g:master Etienne, could you please take a look? Thanks!
Attachment #8671426 -
Flags: review?(etienne)
Comment 23•9 years ago
|
||
Comment on attachment 8671426 [details] [review] [gaia] albertopq:1188350-title-window-open > mozilla-b2g:master Looking good!
Attachment #8671426 -
Flags: review?(etienne) → review+
Assignee | ||
Comment 24•9 years ago
|
||
master: https://github.com/mozilla-b2g/gaia/commit/a068470f78d2c6038e7cde2027b12330b5d7696b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
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
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in
before you can comment on or make changes to this bug.
Description
•