Last Comment Bug 690056 - Implement visibility api
: Implement visibility api
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla10
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
http://www.w3c-test.org/webperf/specs...
Depends on: 698057 1121701
Blocks: webapi 679966
  Show dependency treegraph
 
Reported: 2011-09-28 13:00 PDT by Boris Zbarsky [:bz]
Modified: 2015-01-14 18:09 PST (History)
15 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Implement a vendor-prefixed version of the document parts of the visibility API. (30.93 KB, patch)
2011-09-30 14:09 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Splinter Review
Implement a vendor-prefixed version of the visibility API. idea is to fire the visibilitychange event synchronously during pageshow and pagehide, since we're (31.21 KB, patch)
2011-09-30 14:12 PDT, Boris Zbarsky [:bz]
jonas: review+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] 2011-09-28 13:00:35 PDT
To do it per spec, we need a fix for bug 443316.

Do we want to do a moz-prefixed impl with moz-prefixed numeric constants instead for now?
Comment 1 Boris Zbarsky [:bz] 2011-09-28 13:03:30 PDT
Or we could not have those constants for now; just the two properties.  That seems ok to me.
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-09-28 13:43:27 PDT
Paul, is there anything else you'd want from bug 674701 after we finish this?  I.e. what do you want that Page Visibility doesn't provide, or do you have specific browser bugs in mind with existing Page Visibility implementations that we should avoid here.
Comment 3 Paul Bakaus 2011-09-29 06:29:23 PDT
Hi Chris,

glad  you're asking. Here are the common usecases I want to see covered:

- notification when the browser is hidden because of a phone call
- notification when the engine is halted (most mobile OS'ses halt the browser threat in some cases)

A page can technically be visible but still 'frozen' - easiest example is an alert(). I think window focus events might be enough if implemented correctly to cover this.

Does this help?
Comment 4 Boris Zbarsky [:bz] 2011-09-30 14:09:10 PDT
Created attachment 563842 [details] [diff] [review]
Implement a vendor-prefixed version of the document parts of the visibility API.
Comment 5 Boris Zbarsky [:bz] 2011-09-30 14:12:55 PDT
Created attachment 563844 [details] [diff] [review]
Implement a vendor-prefixed version of the visibility API.   idea is to fire the visibilitychange event synchronously during pageshow and pagehide, since we're
Comment 6 Andreas Gal :gal 2011-09-30 15:33:45 PDT
++bz, this totally rocks
Comment 7 Boris Zbarsky [:bz] 2011-09-30 18:14:28 PDT
One drawback: when we drop the vendor prefix any content written against this code will break unless it's also checking the non-prefixed bits...
Comment 8 Brendan Eich [:brendan] 2011-09-30 19:03:56 PDT
Are vendor prefixes still considered net positives? See Henri's comment at

http://robert.ocallahan.org/2011/09/shifts-in-promoting-open-web.html?showComment=1317367673501#c5792712052968222061

/be
Comment 9 Boris Zbarsky [:bz] 2011-09-30 19:45:38 PDT
That's a good question, yes.

I think Henri's real issue is with the timeframe it takes to get to CR.  I fully expect this spec to be in CR within a few months, so that the vendor prefixes will go away then.  The benefits of small specs.

In the meantime, I made a bunch of implementation calls that the spec does not define yet and I'm not sure about, so I want to prefix just to make sure we don't get locked into those.  I _think_ I made the right tradeoffs, but it's not obvious.
Comment 10 Jonas Sicking (:sicking) PTO Until July 5th 2011-10-10 16:20:51 PDT
Comment on attachment 563844 [details] [diff] [review]
Implement a vendor-prefixed version of the visibility API.   idea is to fire the visibilitychange event synchronously during pageshow and pagehide, since we're

Review of attachment 563844 [details] [diff] [review]:
-----------------------------------------------------------------

I'm surprised that only calling PostVisibilityUpdateEvent in one location covers all cases. Does it cover display:none iframes getting hidden? I couldn't see a test for that.

Or do we not want to do that yet given the discussion on the mailing list?

::: content/base/src/nsDocument.cpp
@@ +8727,5 @@
> +nsDocument::GetVisibilityState() const
> +{
> +  // We have to check a few pieces of information here:
> +  // 1)  Are we in bfcache (!IsVisible())?  If so, nothing else matters;
> +  //     we

There seems to be an end to the sentence missing.
Comment 11 Boris Zbarsky [:bz] 2011-10-10 21:39:50 PDT
> Does it cover display:none iframes getting hidden?

No.  For now, I'm not doing anything special for display:none iframes, just like other browsers do not.  The version of this patch in my tree in fact has a test for that non-specialness.

It would be pretty simple to change that if we want, of course.

> There seems to be an end to the sentence missing.

There should just be a period after "matters" and no trailing "we".  Fixed.
Comment 12 Jonas Sicking (:sicking) PTO Until July 5th 2011-10-10 21:56:17 PDT
Comment on attachment 563844 [details] [diff] [review]
Implement a vendor-prefixed version of the visibility API.   idea is to fire the visibilitychange event synchronously during pageshow and pagehide, since we're

Cool, sounds good with that.
Comment 14 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-10-12 03:15:46 PDT
https://hg.mozilla.org/mozilla-central/rev/c7b4452ef1d2
Comment 15 Boris Zbarsky [:bz] 2013-01-10 06:32:42 PST
https://developer.mozilla.org/en-US/docs/DOM/Using_the_Page_Visibility_API has existed for a while.

Note You need to log in before you can comment on or make changes to this bug.