Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 10:58 AM Tom Ritter wrote: > On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari > wrote: > > What are your plans with regards to implementing the second part? Can > > these reports be sent cross-origin? (From the spec, it seems like the > > answer is yes.) If so, how are you planning to handle issues such as > > sending these reports to third-parties, including third-party trackers? > > I'm worried about: a) sending these reports to a third-party not on the > TP > > list, b) sending these reports to a third-party on the TP list, and c) > what > > options we have to mitigate the tracking impact of these reports for both > > of the previous cases, but especially for (b). > > Is this a different situation than CSP, which seems to have all these > same issues? Do we do anything special there? > The CSP report-uri mechanism is deprecated AFAIK ( https://w3c.github.io/webappsec-csp/#directive-report-uri) and is supposed to be replaced with this new API, so I think it is important to get the new API right from the privacy perspective even if we didn't get CSP reporting right (which we didn't -- AFAIK we happily send the CSP violation reports to wherever the site points us to.) -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On 11/13/18 10:33 AM, Andrea Marchesini wrote: *Summary*: Reporting API allows the page to receive notifications such as the usage of deprecated APIs and FeaturePolicy violations. I decided to implement this API, because it is required in the web-platform-tests for FeaturePolicy. Reporting API covers 2 different features: a. reporting to the current page, via ReportingObserver b. reporting to a remote server, known via 'report-to' HTTP header. My implementation covers only the first aspect. However I also have patches for the second part, not in review yet. It is blatantly clear to me that the second part would be a violation of the GDPR. I raised this issue in: https://bugzilla.mozilla.org/show_bug.cgi?id=1492036#c9 No one has yet responded. It may very well be that the first part also violates the GDPR if it gives the page access to data that it would not otherwise have access to. Isn't the whole purpose of the ReportingObserver to facilitate sending data back to an external server through some other mechanism like XHR? /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: css-scroll-anchoring
Scroll anchoring should benefit both desktop and mobile content. I have a feeling the biggest impact will be on mobile though. Scroll anchoring should help there when the viewport resizes from a rotation, not just as content loads. There's a good video in the Chrome announcement here [1]. I've also written two sample pages that you can compare between Blink and Gecko [2] [3]. Scroll down and interact with the button/slider. Thanks, Ryan [1] https://blog.chromium.org/2017/04/scroll-anchoring-for-web-developers.html [2] https://eqrion.github.io/web-tests/scrolling/scroll-anchor-test-1.html [3] https://eqrion.github.io/web-tests/scrolling/scroll-anchor-test-2.html ‐‐‐ Original Message ‐‐‐ On Wednesday, November 14, 2018 3:44 PM, Chris Peterson wrote: > This is great news! In a recent study of Fennec's perceived performance, > users ranked 16 criteria for evaluating mobile browser responsiveness. > #1 was "Not having the page jump around when scrolling". For a point of > reference for just how important that is, "Loading a website" was only > #3. :) > > Will scroll anchoring benefit both desktop and mobile content? What is a > good example website to see the effect of scroll anchoring? > > On 2018-11-14 1:09 PM, Ryan Hunt wrote: > > > Apologies. The target release is 66, while Chrome released this feature in > > M56. > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, November 14, 2018 3:05 PM, Ryan Hunt rh...@eqrion.net wrote: > > > > > Summary: > > > Scroll anchoring aims to prevent user experience disruptions from content > > > loading outside the viewport and causing the page to jump around. > > > Bug: Bug 1305957 > > > Link to standard: > > > https://drafts.csswg.org/css-scroll-anchoring/ > > > Platform coverage: All platforms > > > Estimated or target release: 56 > > > Preference behind which this will be implemented: > > > layout.scroll-anchoring.enabled > > > Is this feature enabled by default in sandboxed iframes? Yes > > > DevTools bug: No bug > > > Do other browser engines implement this? > > > Chrome shipped this in M56. > > > web-platform-tests: > > > https://github.com/web-platform-tests/wpt/tree/master/css/css-scroll-anchoring > > > Is this feature restricted to secure contexts? > > > No. Scrolling behavior changes aren't restricted to secure contexts. > > > Thanks, > > > Ryan > > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: css-scroll-anchoring
This is great news! In a recent study of Fennec's perceived performance, users ranked 16 criteria for evaluating mobile browser responsiveness. #1 was "Not having the page jump around when scrolling". For a point of reference for just how important that is, "Loading a website" was only #3. :) Will scroll anchoring benefit both desktop and mobile content? What is a good example website to see the effect of scroll anchoring? On 2018-11-14 1:09 PM, Ryan Hunt wrote: Apologies. The target release is 66, while Chrome released this feature in M56. ‐‐‐ Original Message ‐‐‐ On Wednesday, November 14, 2018 3:05 PM, Ryan Hunt wrote: Summary: Scroll anchoring aims to prevent user experience disruptions from content loading outside the viewport and causing the page to jump around. Bug: Bug 1305957 Link to standard: https://drafts.csswg.org/css-scroll-anchoring/ Platform coverage: All platforms Estimated or target release: 56 Preference behind which this will be implemented: layout.scroll-anchoring.enabled Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: No bug Do other browser engines implement this? Chrome shipped this in M56. web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/css/css-scroll-anchoring Is this feature restricted to secure contexts? No. Scrolling behavior changes aren't restricted to secure contexts. Thanks, Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: css-scroll-anchoring
Apologies. The target release is 66, while Chrome released this feature in M56. ‐‐‐ Original Message ‐‐‐ On Wednesday, November 14, 2018 3:05 PM, Ryan Hunt wrote: > Summary: > > Scroll anchoring aims to prevent user experience disruptions from content > loading outside the viewport and causing the page to jump around. > > Bug: Bug 1305957 > > Link to standard: > > https://drafts.csswg.org/css-scroll-anchoring/ > > Platform coverage: All platforms > > Estimated or target release: 56 > > Preference behind which this will be implemented: > layout.scroll-anchoring.enabled > > Is this feature enabled by default in sandboxed iframes? Yes > > DevTools bug: No bug > > Do other browser engines implement this? > > Chrome shipped this in M56. > > web-platform-tests: > > https://github.com/web-platform-tests/wpt/tree/master/css/css-scroll-anchoring > > Is this feature restricted to secure contexts? > > No. Scrolling behavior changes aren't restricted to secure contexts. > > Thanks, > Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: css-scroll-anchoring
Summary: Scroll anchoring aims to prevent user experience disruptions from content loading outside the viewport and causing the page to jump around. Bug: Bug 1305957 Link to standard: https://drafts.csswg.org/css-scroll-anchoring/ Platform coverage: All platforms Estimated or target release: 56 Preference behind which this will be implemented: layout.scroll-anchoring.enabled Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: No bug Do other browser engines implement this? Chrome shipped this in M56. web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/css/css-scroll-anchoring Is this feature restricted to secure contexts? No. Scrolling behavior changes aren't restricted to secure contexts. Thanks, Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
> Is it needed for any other reason? If not, this seems like a bug in the > tests: they should not be coupling the two specs together. > Well, in this way, these 2 APIs can test each other: we could use deprecated APIs to check ReportingObserver notifications, but there is not a common set of deprecated APIs across browsers. And ReportingObserver is an easy way to test any feature-policy blocking with a common code base. See: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/feature-policy/reporting ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On 11/13/18 4:33 AM, Andrea Marchesini wrote: I decided to implement this API, because it is required in the web-platform-tests for FeaturePolicy. Is it needed for any other reason? If not, this seems like a bug in the tests: they should not be coupling the two specs together. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari wrote: > What are your plans with regards to implementing the second part? Can > these reports be sent cross-origin? (From the spec, it seems like the > answer is yes.) If so, how are you planning to handle issues such as > sending these reports to third-parties, including third-party trackers? > I'm worried about: a) sending these reports to a third-party not on the TP > list, b) sending these reports to a third-party on the TP list, and c) what > options we have to mitigate the tracking impact of these reports for both > of the previous cases, but especially for (b). Is this a different situation than CSP, which seems to have all these same issues? Do we do anything special there? -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: overflow-wrap: anywhere
Finally something what solving problem of missing "word-break: break-word" (https://jsfiddle.net/ofgd83um/80/) When it will be shipped to stable? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Tue, Nov 13, 2018 at 4:33 AM Andrea Marchesini wrote: > Reporting API covers 2 different features: > a. reporting to the current page, via ReportingObserver > b. reporting to a remote server, known via 'report-to' HTTP header. > My implementation covers only the first aspect. However I also have patches > for the second part, not in review yet. > What are your plans with regards to implementing the second part? Can these reports be sent cross-origin? (From the spec, it seems like the answer is yes.) If so, how are you planning to handle issues such as sending these reports to third-parties, including third-party trackers? I'm worried about: a) sending these reports to a third-party not on the TP list, b) sending these reports to a third-party on the TP list, and c) what options we have to mitigate the tracking impact of these reports for both of the previous cases, but especially for (b). Also, do I understand correctly that ReportingObserver objects only receive reports from the same origin as the context they're created in? Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: overflow-wrap: anywhere
Finally something can slove problem of missing "word-break: break-word" https://jsfiddle.net/ofgd83um/80/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
