812086 - Unprefix Page Visibility API

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Masataka Yakura [:myakura]]

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 [:bzbarsky]]

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 [:myakura]]

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 [:bzbarsky]]

Attachment: part 1. Add unprefixed version of page visibility API.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: part 2. Convert internal consumers of mozvisibilitychange events to the unprefixed version.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: part 3. Convert internal consumers of mozHidden and mozVisibilityState to the unprefixed versions.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

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 [:bzbarsky]]

> 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][[e-mail]]]

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]

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 [:bzbarsky]]

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 [:bzbarsky]]

Attachment: part 4. Warn when consumers use the moz-prefixed versions of visibility API.

Comment 12

[Boris Zbarsky [:bzbarsky]]

   https://hg.mozilla.org/integration/mozilla-inbound/rev/62ed3f621105
   https://hg.mozilla.org/integration/mozilla-inbound/rev/b29bb769336a
   https://hg.mozilla.org/integration/mozilla-inbound/rev/8b68a81be38a
   https://hg.mozilla.org/integration/mozilla-inbound/rev/4e314111b45a

Comment 13

[Boris Zbarsky [:bzbarsky]]

I filed bug 812701.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/62ed3f621105
https://hg.mozilla.org/mozilla-central/rev/b29bb769336a
https://hg.mozilla.org/mozilla-central/rev/8b68a81be38a
https://hg.mozilla.org/mozilla-central/rev/4e314111b45a

Comment 16

[Alex Keybl [:akeybl]]

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 [:bzbarsky]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c141f818c5b3

Comment 18

[Jorge Villalobos [:jorgev] (he/him)]

(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 [:bzbarsky]]

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] (he/him)]

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 [:bzbarsky]]

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.

Comment 22

[Jean-Yves Perrier [:teoli]]

Updated:
https://developer.mozilla.org/en-US/docs/Mozilla_Event_Reference/visibilitychange and
https://developer.mozilla.org/en-US/docs/Firefox_18_for_developers