1506655 - Confusing behavior when toggling toolbars in popups

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Tooru Fujisawa [:arai]]

Attachment: testcase

Steps to reproduce:
  1. run Nightly 65.0a1 (2018-11-12) (64-bit) with clean profile on macOS
  2. open attached file
  3. click "open window" button
  4. allow popup and open let the window open
  5. close the first window that has attached file opened
     (so that there's only the window opened by the attached file)
  6. secondary click on empty area of tab bar and choose "Bookmarks toolbar"
  7. secondary click on empty area again
  8. open about:preferences
  9. check [General] - [Startup] - [Restore previous session]
 10. shutdown Nightly
 11. run Nightly again
 12. secondary click on empty area again

Actual result:
  in step 6, Bookmarks toolbar is not shown.
  in step 7, "Bookmarks toolbar" item in the menu is checked.
  in step 11, Bookmarks toolbar is still not shown (happens after firefox 61, bug 1034036)
  in step 12, "Bookmarks toolbar" item in the menu is still checked (happens after firefox 61, bug 1034036)

Expected result:
  not sure where to fix, but maybe one of:
    * somehow make it clear that the window is opened by web content
      and Bookmarks toolbar is hidden by that regardless of UI option
      (if other UI items are hidden, it's clearer, but this case it's hard to notice)
    * disable the "Bookmarks toolbar" menu item for such window
      (context menu on toolbar, and [View] menu in menu bar, maybe some more?)
    * do not keep such state across session store (regression from bug 1034036),
      so that this strange behavior can at least be fixed by restart
    * do not let web content open such window

Comment 1

[Tooru Fujisawa [:arai]]

:mikedeboer, what was the reason why "hidden" state is changed to kept in bug 1034036 ?
  https://hg.mozilla.org/mozilla-central/rev/6ce9efe2b20d#l1.31
maybe it was not intentional to remove the "hidden" state for a window that is opened by web content?

Comment 2

[Tooru Fujisawa [:arai]]

clarification about tracking flag.
firefox-esr60 is affected only about issues in steps 6 and 7.
steps 11 and 12 (after restart) are from firefox 61

Comment 3

[Tooru Fujisawa [:arai]]

bz, can I have your opinion about that web content being able to open such window? (the window that looks almost like normal Firefox window, but bookmark toolbar cannot be shown)
any chance that feature can be removed from window.open?

Comment 4

[Mike de Boer [:mikedeboer]]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> :mikedeboer, what was the reason why "hidden" state is changed to kept in
> bug 1034036 ?
>   https://hg.mozilla.org/mozilla-central/rev/6ce9efe2b20d#l1.31
> maybe it was not intentional to remove the "hidden" state for a window that
> is opened by web content?

Well, first off I thought it was a nice improvement to not indiscriminately skip saving window state properties - because we weren't making a distinction based on some deterministic indicator that we shouldn't save those properties for specific types of windows only.
Apart from that, I don't think it'd be proper architecture to overload Sessionstore with that logic. I'm open to adding a mechanism to _explicitly_ tell Sessionstore to stop tracking specific properties for specific windows, but that's not there atm. We do this implicitly and internally for private windows already.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> bz, can I have your opinion about that web content being able to open such window? 

It's a very longstanding behavior, dating back to Netscape 3 or so.

We could consider revisiting it; we'd need to do some testing to see what other browsers do.

Comment 6

[Tooru Fujisawa [:arai]]

Attachment: testcase

just noticed the testcase is broken :P

I'll check the other browser's behavior

Comment 7

[Tooru Fujisawa [:arai]]

Edge
  * Has Favorites bar
  * The testcase opens a window that has only location bar
    * Tabs, favorites bar, Forward/Backward/Reload buttons, are not shown
    * Cannot open new tab
      * Hitting Ctrl+T does nothing on the window
  * The window opened by the testcase is not restored on restart
    (If I configured to restore session)
    * The other windows are restored
    * If the window that is opened by testcase was the last window,
      the last window that is closed before it is restored

Chrome
  * Has Bookmarks bar
  * The testcase opens a window that has only location bar
    * Tabs, favorites bar, Forward/Backward/Reload buttons, are not shown
    * Cannot open new tab in the window
      * Hitting Ctrl+T opens new tab in the another normal window
  * The window opened by the testcase is not restored on restart
    (If I configured to restore session)
    * If the window that is opened by testcase was the last window,
      the last window that is closed before it is restored

Safari
  * No Bookmarks bar
  * The testcase opens a window that looks like normal window
    * Forward/Backward/Reload buttons are shown
    * Can open new tab, and tabs are shown when there's 2 or more tabs
  * The window opened by the testcase is restored on restart
    (If I configured to restore session)

So, Edge and Chrome have similar behavior, that the window opened by web content can only have location bar, and the window is not the target of session restore.

Safari has another behavior that web content cannot control UI parts, and the window opened by web content is same as normal window, and restored on session restore.

Comment 8

[Tooru Fujisawa [:arai]]

there 2 decisions needed:
  * whether to drop support for some "features" (tabbar, toolbar, menubar, personalbar)
    * if we drop support and open window with location bar, it aligns with Edge and Chrome
    * if we drop support and open plain-normal window, it align with Safari
  * whether to restore the window opened by window.open
    * this will apply only when we open not-normal window

I'll file another bug to think about window.open's features parameter,
and revisit the UI side (session restore, UI parts) once its somehow solved.
(like, maybe add another option to sessionrestore to not to restore certain window, instead of removing "hidden" property)

Comment 9

[Dão Gottwald [:dao]]

(In reply to Tooru Fujisawa [:arai] from comment #0)
>     * disable the "Bookmarks toolbar" menu item for such window

This seems reasonable and should be easy enough to do.

Comment 10

[Tooru Fujisawa [:arai]]

Bug 1507375 fixed this.