777825 - visibilitychange events not fired when Firefox is hidden with Cmd-H (Command-H) and then restored with Cmd-Tab

Status: NEW

(Firefox :: General, defect)

Description

[Ian Bicking (:ianbicking)]

The visibilitychange/mozvisibilitychange event does not fire when Firefox is minimized and then unminimized.

To reproduce:

The page at http://app1.ianbicking.org/visibilitytest.html shows when the (moz)visibilitychange even fires.  If you load the page, switch away from the tab, and switch back, the event fires as expected.  If you load the page, minimize Firefox, and then switch back to Firefox, the event does not fire.

This behavior is the same as Chrome.  This page suggests that Chrome should show a page as hidden when the page is minimized, but this does not seem accurate: https://developers.google.com/chrome/whitepapers/pagevisibility

The specification also states the document should be marked as hidden when the window is minimized: http://www.w3c-test.org/webperf/specs/PageVisibility/#sec-document-interface

(I have only tested this on Mac)

Comment 1

[Boris Zbarsky [:bzbarsky]]

I just loaded the page at http://app1.ianbicking.org/visibilitytest.html and then minimized and restored the window.  The output box says:

mozvisibilitychange hidden: true state: hidden at 4168
mozvisibilitychange hidden: false state: visible at 6426

this is a current nightly on Mac.

What exact build are you testing and how are you testing it?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and I minimized by clicking the yellow "-" button (middle button at the top left of the titlebar) and restored by clicking the resulting icon in the Dock.  If your steps are different, I'd like to know what they are.

Comment 3

[Ian Bicking (:ianbicking)]

(In reply to Boris Zbarsky (:bz) from comment #2)
> Oh, and I minimized by clicking the yellow "-" button (middle button at the
> top left of the titlebar) and restored by clicking the resulting icon in the
> Dock.  If your steps are different, I'd like to know what they are.

Yes, apparently my steps are different!  I get the same behavior as you with the yellow button.  When I hide with Command-H, then restore the window with Command-Tab, I don't get an event.

I'm using 17.0a1 (2012-07-25)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Aha!

Well, that would be a front-end bug.  Whatever the Command-H thing actually does, the front end then needs to tell the rendering engine that we're now hidden.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that I have no idea what, if anything, the OS tells us when Cmd-H happens.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Sounds like an Apple bug, that we might be able to work around in Cocoa widgets code.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Do people get different results on different versions of OS X?

Comment 8

[Boris Zbarsky [:bzbarsky]]

How is it an Apple bug?  It's a bug in whever UI code would normally make the visibility changes, no?  Or a bug in our widget code if the UI code is never even notified in this case.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> How is it an Apple bug?

Sometimes we get the event (whatever it is) and send it to Gecko.  Sometimes we don't.

Sounds like an Apple bug to me.

But we can't know for sure until somebody digs deeper.  Which won't be for a while, if that somebody is me.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

> This behavior is the same as Chrome.

This makes it look even more like an Apple bug.

Do let us know if the behavior is different on different versions of OS X.

Comment 11

[Boris Zbarsky [:bzbarsky]]

I never get the event when hiding with Cmd-H and then unhiding.  Do you get it when you do that?

Comment 12

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #11)

No, I never see the Gecko visibility events when hiding (with Cmd-H or from the app menu) or unhiding.  And I always see them minimizing and unminimizing.

I tested on OS X 10.5.8 through 10.8, with FF 14.0.1 (on 10.5.8 and above) and today's mozilla-central nightly (on 10.6.8 and above).

So you're right, Boris.  This does look like a bug in Cocoa widget code.  I'll need to find out how to hook the native hide and unhide events.

I hadn't read the bug carefully enough, and so didn't fully realize how it had morphed.  Sorry for the confusion.

Comment 13

[Boris Zbarsky [:bzbarsky]]

So for reference, the reason visibility events fire on minimize/unminimize is that nsWebShellWindow::HandleEvent, when it sees an NS_SIZEMODE event, fires a sizemodechange event on the XUL <window>, and the tabbrowser code listens for those and does:

2507                 this.mCurrentBrowser.docShellIsActive =
2508                   (window.windowState != window.STATE_MINIMIZED);

(this is in tabbrowser.xml, in the <method name="handleEvent">).

So we'd need to have widget notify the webshell window and that would need to notify the UI code.  Not sure whether it makes sense to treat the hide/unhide as a sizemode change or not.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Thanks, Boris.  So this is more complicated than I thought in comment 12.

Part of me thinks we should add support for nsIDOMChromeWindow::STATE_HIDDEN to cross-platform code, rather than try to overload nsIDOMChromeWindow::STATE_MINIMIZED.

But I've no idea how difficult this would be, or whether it'd be worth the trouble.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Adding a STATE_HIDDEN would certainly make sense to me.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Another complication:

On OS X, it's technically the *app* that's hidden, though all the app's visible windows also get hidden.

The relevant notifications are NSApplicationDidHideNotification, NSApplicationDidUnhideNotification, NSApplicationWillHideNotification and NSApplicationWillUnhideNotification.