info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intent to Implement and Ship: window.screenLeft and window.screenTop aliases
51 views
Skip to first unread message
Emilio Cobos Álvarez
Oct 16, 2018, 6:02:42 PM10/16/18
to dev-pl...@lists.mozilla.org
(Trying to be more disciplined about pinging dev-platform@ about
web-exposed changes, a few other emails will come up in a bit)
Summary:
I plan to add the screenLeft and screenTop properties to the window, as
aliases of screenX and screenY respectively, mostly for compat with
other engines.
See https://github.com/w3c/csswg-drafts/issues/1091 for all the context.
Basically all other engines support it except Gecko.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498860
It's not in the spec yet, but there's a spec PR adding it waiting on
tests to be merged:
https://github.com/w3c/csswg-drafts/pull/2669
Platform coverage: All
Estimated or target release: 64
Preference behind which this will be implemented: none
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
web-platform-tests: https://github.com/web-platform-tests/wpt/pull/13543
I've verified that my implementation passes them of course, with the fix
to them I've suggested in the review.
Is this feature restricted to secure contexts? No, this is a legacy
interop issue and as such I don't think there's any point in restricting
it to secure contexts since the aliased properties are exposed everywhere.
-- Emilio
web-exposed changes, a few other emails will come up in a bit)
Summary:
I plan to add the screenLeft and screenTop properties to the window, as
aliases of screenX and screenY respectively, mostly for compat with
other engines.
See https://github.com/w3c/csswg-drafts/issues/1091 for all the context.
Basically all other engines support it except Gecko.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1498860
It's not in the spec yet, but there's a spec PR adding it waiting on
tests to be merged:
https://github.com/w3c/csswg-drafts/pull/2669
Platform coverage: All
Estimated or target release: 64
Preference behind which this will be implemented: none
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
web-platform-tests: https://github.com/web-platform-tests/wpt/pull/13543
I've verified that my implementation passes them of course, with the fix
to them I've suggested in the review.
Is this feature restricted to secure contexts? No, this is a legacy
interop issue and as such I don't think there's any point in restricting
it to secure contexts since the aliased properties are exposed everywhere.
-- Emilio
Tom Ritter
Oct 17, 2018, 9:05:07 AM10/17/18
to Emilio Cobos Álvarez, Mozilla
I believe that we fiddle these for Resist Fingerprinting; can you ensure
the new values are similarly fiddled?
-tom
On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez <emi...@crisal.io>
wrote:
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
the new values are similarly fiddled?
-tom
On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez <emi...@crisal.io>
wrote:
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Emilio Cobos Álvarez
Oct 17, 2018, 9:30:58 AM10/17/18
to Tom Ritter, Mozilla
On 10/17/18 3:04 PM, Tom Ritter wrote:
> I believe that we fiddle these for Resist Fingerprinting; can you ensure
> the new values are similarly fiddled?
Yeah, they reuse literally the same code path, so they also have the
> I believe that we fiddle these for Resist Fingerprinting; can you ensure
> the new values are similarly fiddled?
same fiddling for RFP.
-- Emilio
> https://lists.mozilla.org/listinfo/dev-platform
>
0 new messages