Unprefix Page Visibility API

RESOLVED FIXED in Firefox 18

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: Masataka Yakura, Assigned: bz)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

Trunk
mozilla19
dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox18 fixed)

Details

Attachments

(4 attachments)

(Reporter)

Description

5 years ago
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.
Component: Untriaged → DOM
Product: Firefox → Core
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Keywords: dev-doc-needed
(Reporter)

Comment 2

5 years ago
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/
Created attachment 682617 [details] [diff] [review]
part 1.  Add unprefixed version of page visibility API.
Attachment #682617 - Flags: review?(bugs)
Created attachment 682618 [details] [diff] [review]
part 2.  Convert internal consumers of mozvisibilitychange events to the unprefixed version.
Attachment #682618 - Flags: review?(bugs)
Created attachment 682619 [details] [diff] [review]
part 3.  Convert internal consumers of mozHidden and mozVisibilityState to the unprefixed versions.
Attachment #682619 - Flags: review?(bugs)
Assignee: nobody → bzbarsky
Whiteboard: [need review]

Updated

5 years ago
Attachment #682617 - Flags: review?(bugs) → review+

Updated

5 years ago
Attachment #682618 - Flags: review?(bugs) → review+

Updated

5 years ago
Attachment #682619 - Flags: review?(bugs) → review+

Comment 6

5 years ago
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?

Updated

5 years ago
Blocks: 775235
> 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

5 years ago
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.
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.
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?
Keywords: addon-compat
Created attachment 682671 [details] [diff] [review]
part 4.  Warn when consumers use the moz-prefixed versions of visibility API.
Attachment #682671 - Flags: review?(bugs)

Updated

5 years ago
Attachment #682671 - Flags: review?(bugs) → review+
   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
Flags: in-testsuite+
OS: Windows 7 → All
Hardware: x86 → All
Whiteboard: [need review]
Target Milestone: --- → mozilla19
I filed bug 812701.
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.
Attachment #682617 - Flags: approval-mozilla-aurora?
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
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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.
Attachment #682617 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/c141f818c5b3
status-firefox18: --- → fixed
(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.
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.
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.
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.
Keywords: addon-compat
Updated:
https://developer.mozilla.org/en-US/docs/Mozilla_Event_Reference/visibilitychange and
https://developer.mozilla.org/en-US/docs/Firefox_18_for_developers
Keywords: dev-doc-needed → dev-doc-complete
Blocks: 1237175
You need to log in before you can comment on or make changes to this bug.