Closed Bug 812086 Opened 12 years ago Closed 12 years ago

Unprefix Page Visibility API

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox18 --- fixed

People

(Reporter: myakura.web, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(4 files)

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
Keywords: dev-doc-needed
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/
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Attachment #682617 - Flags: review?(bugs) → review+
Attachment #682618 - Flags: review?(bugs) → review+
Attachment #682619 - Flags: review?(bugs) → review+
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?
> 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.
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
Attachment #682671 - Flags: review?(bugs) → review+
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?
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+
(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
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.