Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
Hi, DBaron, I would like to support the creation of Timed Media Working Group. Because Media Capture is one of other deliverables, I would like to put the work[1] to this working group. Thanks. [1]: http://chiahungtai.github.io/mediacapture-worker/ BR, CTai 2015-08-10 2:59 GMT+08:00 L. David Baron dba...@dbaron.org: The W3C is proposing revised charters for: Web Platform Working Group: http://www.w3.org/2015/07/web-platform-wg.html https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html Timed Media Working Group http://www.w3.org/2015/07/timed-media-wg.html https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html The Web Platform Working Group ***replaces the HTML and WebApps Groups***. The Timed Media WG splits some of the media work that was happening in HTML (MSE, EME) into a separate group. Mozilla has the opportunity to send comments or objections through Thursday, September 10. Please reply to this thread if you think there's something we should say as part of this charter review. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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 Ship: Updated third-party iframe storage behavior
Is this pref something that's exposed to users, or is it only about:config (I can't seem to find any UI for it)? If so, this seems like a step away from being able to ever expose it as more apps will be built assuming IndexedDB will be unconditionally available in 3rd party iframes. This change would make the 'it breaks the web argument' against exposing it stringer. From my perspective, this would be undesirable. On Tue, Aug 18, 2015, at 04:20 PM, Michael Layzell wrote: Summary: Currently, there are inconsistent rules about the availability of persistent storage in third-party iframes across different types of storage (such as caches, IndexedDB, localstorage, sessionstorage, and cookies). We are looking to unify these behaviors into a consistent set of rules for when persistent storage should be available. We have modeled this after our cookie rules, and now use the cookie behavior preference to control third party access to these forms of persistent storage. This means that IndexedDB (which was previously unconditionally disabled in 3rd-party iframes) is now available in 3rd party iframes when the accept third-party cookies preference is set to Always. As our current definition of accepting third-party cookies from Only Visited makes no sense for non-cookie storage, we currently treat this preference for these forms of storage as though the preference was Never. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1184973 Link to standard: N/A. Platform coverage: All platforms. Target release: Firefox 43. Preference behind which this will be implemented: None, although the preference network.cookie.cookieBehavior will be used to guide the behavior of storage in third-party iFrames. DevTools bug: N/A. Do other browser engines implement this: Based on my quick testing: Chrome uses it's third party preference to control access to localStorage and sessionStorage, but not IndexedDB or caches. Safari appears to use it's preference to control IndexedDB, but not sessionStorage or localStorage. IE appears to only use its 3rd party preference for cookies. All other browsers allow IndexedDB in 3rd party iframes with default settings. Security Privacy Concerns: This changes how websites can store data on the user's machine. Web designer / developer use-cases: Previously, we had made IndexedDB unavailable in 3rd-party iframes. Web developers will now be able to use IndexedDB in 3rd party iframes when the user has the accept cookies preference set to always. Michael ___ 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: Allowing web apps to delay layout/rendering on startup
On Friday, August 14, 2015 at 3:59:23 PM UTC-7, James Burke wrote: There does not seem to be a need for extra APIs in the browser for controlling layouts or paints using this approach: Great work James! I like that we can play with this approach right now, but I'm wondering if we should still pursue some API to facilitate this behavior for the Web. My concern here is that if we don't, we're basically saying that the right way to write webapps, is to put their content in a template and then inject the template into body when we're done with startup JS. That feels like a dirty hack, not sure how accessible it is, and it will literally do nothing in a scenario of any JS error. The API, even as a sugar coating on top of the heuristic you described, would not only solve the problems but also enable us to provide better UX for error case scenarios (your APP did not load properly, restart?) and open up possibilities for the engine to optimize for it (maybe HTML/CSS parsing should happen in parallel with init JS?). zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: Updated third-party iframe storage behavior
On 2015-08-18 5:37 PM, Tanvi Vyas wrote: It is nice to see that we are moving towards an Accept third party cookies and data setting instead of just Allow third party cookies. Will localstorage and sessionstorage also start honoring the users blocking preferences soon? Yes, that is part of this project. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decreasing quality?
On Mon, 17 Aug 2015, Dirkjan Ochtman wrote: I have an anecdote, and was wondering if others can corroborate: it seems to me that Nightly's quality has been getting worse recently (this is on latest OS X, rMBP). 2. 1193796 -- Unable to access Google properties with Firefox Nightly This confuses me greatly. This particular bug is Linux-only, thus not affecting you on OS X... -- / daniel.haxx.se ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 18 Aug 2015 at 4:00PM PDT
Today's MemShrink meeting is brought to you by cycle-free media buffers: https://bugzilla.mozilla.org/show_bug.cgi?id=1190019 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 18 Aug 2015, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2015-18-04/16:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 * Triage Etherpad: https://etherpad.mozilla.org/memshrinktriage ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Tue, Aug 18, 2015 at 1:22 PM, Zibi Braniecki zbigniew.branie...@gmail.com wrote: My concern here is that if we don't, we're basically saying that the right way to write webapps, is to put their content in a template and then inject the template into body when we're done with startup JS. There are other approaches too, I expect apps that use an mvc layer with templating (not the template tag), could decide not to use the template tag approach, just leave the body empty until JS injects the content. That feels like a dirty hack, not sure how accessible it is, and it will literally do nothing in a scenario of any JS error. With web components, but even with other MVC systems (react or ember components), or with service workers, we are saying we need app JS to generate views. When the app gets to handle the views it also needs to build its own error fallbacks. I think it is just good app practice to know how to handle errors. I would not be sure what platform API makes sense to recommend either, particularly given the performance captures, where it is unclear what benefit those APIs would provide. You could say the platform has already provided the API: a template tag and a way to hopefully avoid extra rendering work (or at least the annoying initial flash of white) with a transparent background color. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I need to give my 2–coins–worth on this topic, please. (Re: Can we make a plan to retire Universal Mac builds?)
On 2015-08-15 3:02 PM, Cameron Kaiser wrote: On 8/12/15 3:32 PM, Mike Hommey wrote: Relatedly, why does Tenfourfox use a different branding? Because I didn't want to get into the whole Ice* thing again. I have nothing to add to this except to say that this is a pure and noble goal, and I salute you. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: Updated third-party iframe storage behavior
It is nice to see that we are moving towards an Accept third party cookies and data setting instead of just Allow third party cookies. Will localstorage and sessionstorage also start honoring the users blocking preferences soon? On 8/18/15 8:20 AM, Michael Layzell wrote: Summary: Currently, there are inconsistent rules about the availability of persistent storage in third-party iframes across different types of storage (such as caches, IndexedDB, localstorage, sessionstorage, and cookies). We are looking to unify these behaviors into a consistent set of rules for when persistent storage should be available. We have modeled this after our cookie rules, and now use the cookie behavior preference to control third party access to these forms of persistent storage. This means that IndexedDB (which was previously unconditionally disabled in 3rd-party iframes) is now available in 3rd party iframes when the accept third-party cookies preference is set to Always. As our current definition of accepting third-party cookies from Only Visited makes no sense for non-cookie storage, we currently treat this preference for these forms of storage as though the preference was Never. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1184973 Link to standard: N/A. Platform coverage: All platforms. Target release: Firefox 43. Preference behind which this will be implemented: None, although the preference network.cookie.cookieBehavior will be used to guide the behavior of storage in third-party iFrames. DevTools bug: N/A. Do other browser engines implement this: Based on my quick testing: Chrome uses it's third party preference to control access to localStorage and sessionStorage, but not IndexedDB or caches. Safari appears to use it's preference to control IndexedDB, but not sessionStorage or localStorage. IE appears to only use its 3rd party preference for cookies. All other browsers allow IndexedDB in 3rd party iframes with default settings. Security Privacy Concerns: This changes how websites can store data on the user's machine. Web designer / developer use-cases: Previously, we had made IndexedDB unavailable in 3rd-party iframes. Web developers will now be able to use IndexedDB in 3rd party iframes when the user has the accept cookies preference set to always. Michael ___ 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
MozPromises are now in XPCOM
I gave a lightning talk at Whistler about MozPromise and a few other new tools to facilitate asynchronous and parallel programming in Gecko. There was significant interest, and so I spent some time over the past few weeks untangling them from dom/media and hoisting them into xpcom/. Bug 1188976 has now landed on mozilla-central, MozPromise (along with TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be used everywhere in Gecko. I also just published a blog post describing why MozPromises are great and how they work: http://bholley.net/blog/2015/mozpromise.html Feedback is welcome. These tools are intended to allow developers to easily and safely run code on off-main-thread thread pools, which is something we urgently need to do more of in Gecko. Go forth and write more parallel code! bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: Updated third-party iframe storage behavior
On Tue, Aug 18, 2015 at 2:39 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-08-18 5:37 PM, Tanvi Vyas wrote: It is nice to see that we are moving towards an Accept third party cookies and data setting instead of just Allow third party cookies. Will localstorage and sessionstorage also start honoring the users blocking preferences soon? Yes, that is part of this project. Is there a point to having sessionStorage honor this pref? Doesn't it effectively double-key anyway since it ties the data to a given nsIDocShell instance. So there's no way to use that for tracking any more than global variables and URLs? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New policy: 48-hour backouts for major Talos regressions
On Tue, Aug 18, 2015 at 3:43 PM, Chris Pearce cpea...@mozilla.com wrote: We recently had a false positive Talos regression on our team, which turned out to be caused by a change to the test machine coinciding with our push. This took up a bunch of energy and time away from our team, which we really can't afford. So to mitigate that I propose that *before* the backout happens, someone on the regression-detection team does an `hg up` and Try push of the backout and a Try push without the backout to ensure that backing out actually helps. +1. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web APIs docs/tech evangelism/dev team meeting Thursday at 8 AM PDT
The Web API documentation community meeting, with representatives from the technical evangelism and the API development teams, will take place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your time zone). Typical meetings include news about recent API development progress and future development plans, discussions about what the priorities for documenting and promoting new Web technologies should be, and the status of ongoing work to document and evangelize these technologies. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/API-docs-meeting-2015-08-20. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you have topics you wish to discuss, please feel free to add them to the agenda. Also, if you're unable to attend but have information or suggestions related to APIs on the Web, their documentation, and how we promote these APIs, please add a note or item to the agenda so we can be sure to address it, even if you're unable to attend. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability https://freebusy.io/esheph...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decreasing quality?
It's possible this bug was being confused with bug 1195030. Gavin On Tue, Aug 18, 2015 at 2:35 PM, Daniel Stenberg dan...@haxx.se wrote: On Mon, 17 Aug 2015, Dirkjan Ochtman wrote: I have an anecdote, and was wondering if others can corroborate: it seems to me that Nightly's quality has been getting worse recently (this is on latest OS X, rMBP). 2. 1193796 -- Unable to access Google properties with Firefox Nightly This confuses me greatly. This particular bug is Linux-only, thus not affecting you on OS X... -- / daniel.haxx.se ___ 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: New policy: 48-hour backouts for major Talos regressions
We recently had a false positive Talos regression on our team, which turned out to be caused by a change to the test machine coinciding with our push. This took up a bunch of energy and time away from our team, which we really can't afford. So to mitigate that I propose that *before* the backout happens, someone on the regression-detection team does an `hg up` and Try push of the backout and a Try push without the backout to ensure that backing out actually helps. Retriggers on the original push in our case didn't help, so I think a completely clean push is necessary. This should also assist the regression-detection team in convincing patch authors that their patch is at fault. The Try-backout should happen before the need-info to the patch author happens. If the backout has non-trivial merge conflicts, then the first action of the patch author should be to preform this step instead of the regression-detection team member. cpearce. On 8/15/2015 1:02 PM, Vladan Djeric wrote: There are known issues with the test infrastructure (e.g. differences in weekend vs weekday results) and those known issues are currently being masked with human judgement. A-Team has investigated these issues, and fixed some of them, but fixing the rest will take a non-trivial amount of effort as I understand it. When there's enough time to fix all the sources of noise in the infrastructure, human judgement will no longer be required. As an aside, I'm answering the questions for this 48-hour backout announcement, but it's really Joel Maher + William Lachance + Vaibhav Agarwal doing all the heavy lifting related to regression handling. They're working on the regression-detection and regression-investigation tools, and they're the ones acting as perf sheriffs. Avi from my team is helping test the tools, and I just participate in policy discussions and act as an (unintentional) spokesperson :) On Fri, Aug 14, 2015 at 8:49 PM, Martin Thomson m...@mozilla.com wrote: On Fri, Aug 14, 2015 at 3:44 PM, Vladan Djeric vdje...@mozilla.com wrote: Is this the ts_paint regression you're referring to? https://groups.google.com/forum/#!searchin/mozilla.dev.tree-alerts/ts_paint/mozilla.dev.tree-alerts/FArVsa8guXg/FfY91JK7AAAJ Yeah. I only ask because in exercising judgment suppresses information about the stability of the tests, so that all we have is anectodal evidence. That's probably OK here. The process you describe sounds pretty robust against false positives. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New policy: 48-hour backouts for major Talos regressions
On Wednesday 2015-08-19 10:43 +1200, Chris Pearce wrote: We recently had a false positive Talos regression on our team, which turned out to be caused by a change to the test machine coinciding with our push. This took up a bunch of energy and time away from our team, which we really can't afford. I though we'd collectively learned this lesson a number of times in the past, but it seems to keep happening. Machine configuration changes need to either happen in the repository or happen as part of a tree closure in which all runs complete, the configuration change is made, a dummy changeset is pushed to all trees, and the trees reopened. I think this is in violation of https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#Must_avoid_patterns_known_to_cause_non_deterministic_failures (see the first bullet point). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On 2015-08-04 3:08 PM, Jonas Sicking wrote: On Tue, Aug 4, 2015 at 10:06 AM, Bobby Holley bobbyhol...@gmail.com wrote: How about a scheme in which there can be N such meta elements, and the painting only happens when all of them are gone (or some timeout occurs)? That solve the common case that Jonas is talking about, and allows libraries to insert their own paint blocker into head if they really want to block painting? The a nice side-bonus of this scheme is that the existence of blockers is clearly visible in the DOM, so that a buggy library that leaves a paint blocker active is more noticeable. Sold! Sorry for the late response. It seems like we decided to not do anything here for now, but for future reference, the idea above would be impossible to feature detect, which may not be ideal. If we decide to propose something for this in the future, we may want to have a story for feature detection too. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
My assumption was that the preferred fallback would be equivalent to the behavior of the meta element were ignored. I guess people might want to hand-implement their own lazy-loading stuff, but given that the site works without it, most people probably won't. On Tue, Aug 18, 2015 at 6:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-08-04 3:08 PM, Jonas Sicking wrote: On Tue, Aug 4, 2015 at 10:06 AM, Bobby Holley bobbyhol...@gmail.com wrote: How about a scheme in which there can be N such meta elements, and the painting only happens when all of them are gone (or some timeout occurs)? That solve the common case that Jonas is talking about, and allows libraries to insert their own paint blocker into head if they really want to block painting? The a nice side-bonus of this scheme is that the existence of blockers is clearly visible in the DOM, so that a buggy library that leaves a paint blocker active is more noticeable. Sold! Sorry for the late response. It seems like we decided to not do anything here for now, but for future reference, the idea above would be impossible to feature detect, which may not be ideal. If we decide to propose something for this in the future, we may want to have a story for feature detection too. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: Selection Events
Summary: We currently require webpages to poll the current selection when they want to be notified of changes to the user's selection.This patch adds two events, selectstart and selectionchange, which allow the website to detect when the selection is changed. selectstart is fired when the user starts selecting, and selectionchange is fired when the selection changes for any reason. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=571294 Link to standard:http://w3c.github.io/selection-api/#user-interactions Platform coverage:All platforms. Target release: Firefox 43. Preference behind which this will be implemented: dom.select_events.enabled DevTools bug: N/A Do other browser engines implement this: IE, Chrome, and Safari all implement this API. Security Privacy Concerns: This API adds a new mechanism for canceling user selections, which could be abused. However it was already possible. Web designer / developer use-cases: This is a useful tool for websites which wish to be notified when the user's selection changes, as currently websites have to poll the selection in Firefox. Michael ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Ship: Updated third-party iframe storage behavior
Summary: Currently, there are inconsistent rules about the availability of persistent storage in third-party iframes across different types of storage (such as caches, IndexedDB, localstorage, sessionstorage, and cookies). We are looking to unify these behaviors into a consistent set of rules for when persistent storage should be available. We have modeled this after our cookie rules, and now use the cookie behavior preference to control third party access to these forms of persistent storage. This means that IndexedDB (which was previously unconditionally disabled in 3rd-party iframes) is now available in 3rd party iframes when the accept third-party cookies preference is set to Always. As our current definition of accepting third-party cookies from Only Visited makes no sense for non-cookie storage, we currently treat this preference for these forms of storage as though the preference was Never. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1184973 Link to standard: N/A. Platform coverage: All platforms. Target release: Firefox 43. Preference behind which this will be implemented: None, although the preference network.cookie.cookieBehavior will be used to guide the behavior of storage in third-party iFrames. DevTools bug: N/A. Do other browser engines implement this: Based on my quick testing: Chrome uses it's third party preference to control access to localStorage and sessionStorage, but not IndexedDB or caches. Safari appears to use it's preference to control IndexedDB, but not sessionStorage or localStorage. IE appears to only use its 3rd party preference for cookies. All other browsers allow IndexedDB in 3rd party iframes with default settings. Security Privacy Concerns: This changes how websites can store data on the user's machine. Web designer / developer use-cases: Previously, we had made IndexedDB unavailable in 3rd-party iframes. Web developers will now be able to use IndexedDB in 3rd party iframes when the user has the accept cookies preference set to always. Michael ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
