Last Comment Bug 812086 - Unprefix Page Visibility API
: Unprefix Page Visibility API
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla19
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: unprefix 1237175
  Show dependency treegraph
 
Reported: 2012-11-14 23:21 PST by Masataka Yakura
Modified: 2016-01-05 22:40 PST (History)
8 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
part 1. Add unprefixed version of page visibility API. (4.58 KB, patch)
2012-11-16 14:03 PST, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review
part 2. Convert internal consumers of mozvisibilitychange events to the unprefixed version. (15.78 KB, patch)
2012-11-16 14:03 PST, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
Details | Diff | Splinter Review
part 3. Convert internal consumers of mozHidden and mozVisibilityState to the unprefixed versions. (16.38 KB, patch)
2012-11-16 14:03 PST, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
Details | Diff | Splinter Review
part 4. Warn when consumers use the moz-prefixed versions of visibility API. (2.99 KB, patch)
2012-11-16 16:14 PST, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
Details | Diff | Splinter Review

Description Masataka Yakura 2012-11-14 23:21:13 PST
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.19 (KHTML, like Gecko) Chrome/25.0.1325.0 Safari/537.19




Expected results:

The spec went to Candidate Recommendation in July and IE10 and Opera 12.10 shipped with with the API without vendor prefix (IE10 has ms version too though). Gecko can drop moz prefix from its implementation if it's standards compliant.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2012-11-15 07:26:09 PST
Is there a test suite?  Hard to tell what's compliant otherwise.

That said, I think we should just drop the prefix (or rather add a prefix-less version alongside, for now).
Comment 2 Masataka Yakura 2012-11-15 08:43:01 PST
There are some. Microsoft has submitted a few but I'm not sure if they are reviewed.
http://w3c-test.org/webperf/tests/submission/Microsoft/PageVisibility/
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 14:03:18 PST
Created attachment 682617 [details] [diff] [review]
part 1.  Add unprefixed version of page visibility API.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 14:03:36 PST
Created attachment 682618 [details] [diff] [review]
part 2.  Convert internal consumers of mozvisibilitychange events to the unprefixed version.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 14:03:53 PST
Created attachment 682619 [details] [diff] [review]
part 3.  Convert internal consumers of mozHidden and mozVisibilityState to the unprefixed versions.
Comment 6 Olli Pettay [:smaug] 2012-11-16 14:22:57 PST
Comment on attachment 682617 [details] [diff] [review]
part 1.  Add unprefixed version of page visibility API.

Should we add a warning about use of moz* API?
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 14:25:22 PST
> Should we add a warning about use of moz* API?

I suppose we could...  Hard to do for the event, but easy for the other two.  Want me to?

For what it's worth, this seems unused in extensions, so maybe we don't even need to keep the prefixed version.
Comment 8 Olli Pettay [:smaug] 2012-11-16 14:27:52 PST
I think it would be enough to warn about the use of the properties, maybe for one release, 
and then remove the old api and warning after next merge.
Comment 9 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-11-16 14:58:17 PST
Could we uplift this to FF18 on aurora? The  isibility API is quite important to apps so it'd be great to have them use the correct API right away.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 15:02:58 PST
We could, but it's be an addon-compat issue at that point because of the vtable change... and we're about to go to beta on 18.  Jorge, thoughts?
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 16:14:34 PST
Created attachment 682671 [details] [diff] [review]
part 4.  Warn when consumers use the moz-prefixed versions of visibility API.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 17:42:53 PST
I filed bug 812701.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2012-11-16 17:45:35 PST
Comment on attachment 682617 [details] [diff] [review]
part 1.  Add unprefixed version of page visibility API.

Requesting Aurora approval, just for sicking.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None
User impact if declined: b2g apps will have to start out using a version of
   visibility API that we just deprecated.
Testing completed (on m-c, etc.): Passes regression tests.
Risk to taking this patch (and alternatives if risky): Risk is low.  The
   alternative is to not take the patch.
String or UUID changes made by this patch: nsIDOMDocument UUID changed.

If we take this on Aurora, we could go either way on taking the internal+test changes.  My gut feeling is that to mitigate risk we should not take those, so not nominating them.  And definitely not nominating the warning change, since that involves string changes.
Comment 16 Alex Keybl [:akeybl] 2012-11-18 20:59:46 PST
Comment on attachment 682617 [details] [diff] [review]
part 1.  Add unprefixed version of page visibility API.

[Triage Comment]
Low risk fix to prevent API usage fragmentation. The UUID change risk should be manageable, given where we are in the FF18 cycle. Agreed on only landing the necessary patches and mitigating risk bz.

If this is landed on mozilla-aurora before ~11AM PT tomorrow, this will make the merge from Aurora 18 to Beta 18. If landed 11AM-5PM PT tomorrow on mozilla-beta, it will make the first FF18 Beta. If landed after that, it will end up in the second FF18 beta.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2012-11-19 07:23:21 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/c141f818c5b3
Comment 18 Jorge Villalobos [:jorgev] 2012-11-20 14:12:47 PST
(In reply to Boris Zbarsky (:bz) from comment #10)
> We could, but it's be an addon-compat issue at that point because of the
> vtable change... and we're about to go to beta on 18.  Jorge, thoughts?

Sorry for the late reply, but I'm OK with having this on 18. I see a couple of add-ons using these properties, and we'll let them know with the compat bump for whichever version lands with bug 812701 fixed.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2012-11-20 14:16:07 PST
Jorge, the issue is not addons using these properties; those will continue to work.  The issue is binary addons using nsIDOMDocument who will have to recompile if they compiled before the aurora changeset there landed.
Comment 20 Jorge Villalobos [:jorgev] 2012-11-20 15:24:51 PST
That's less of a problem. We set the expectation for binary add-ons to be compiled on Beta, not Aurora. Since this is shipping with the first beta, it should be fine.
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2012-11-20 18:16:32 PST
Ah, great.  I wasn't sure at what point we told people to compile.

Then yeah, this should be all fine.  Removing the addon-compat keyword.

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