Re: MozPromises are now in XPCOM
Hi bholley,
looks great, but a question
The example
mProducer-RequestFoo()
-Then(mThread, __func__,
[...] (ResolveType aVal) { ... },
[...] (RejectType aVal) { ... });
uses C++ lambdas. Do we have some static analysis or such in place to protect
that
lambdas don't refer to raw pointer variables in the scope
(especially raw pointer variables pointing to ref counted objects)?
Or does MozPromise have similar setup to bug 1153295 or what?
-Olli
On 08/19/2015 06:17 AM, Bobby Holley wrote:
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: New policy: 48-hour backouts for major Talos regressions
This is a great point, and I still have no idea what caused the linux 32/64 machines to change on July 30th. It appeared to be a gradual rollout (indicates a machine issue which was picked up on reboot or something similar). For running talos tests we pin to a specific revision in the talos repository, this avoids any issues of pulling from tip. As a side note, we are really close to landing talos in tree, which will reduce one level of complexity in understanding this. Regarding the regression cpearce mentioned- we had done retriggers on the revision and the previous revision after receiving the alert (in the future by a day in this case) to rule out any infrastructure changes. This would be equivalent to doing a try push at that time in point. Sadly enough the numbers only solidified the fact that we had a regression. Yet a couple days later pushing to try and doing retriggers showed a completely different set of numbers. This happens about twice a year historically. Given the stated policy I am fairly certain this would have been backed out (even with a try push) and we would have relanded. We backout patches many times a day for unittest or build failures, and sometimes incorrectly if we mistake the root cause or it is not clear. We have been trying to use similar practices to that of the main tree sheriffs and this 48 hour policy gets us a lot closer. I do think it is valid for us to push to try to verify that the backout fixes the regression. The danger becomes when we have to way 20 hours for try results (now getting to 72 hours) and then other dependencies on the patch in question land. This is why I am skeptical about adding a try push in if we have enough data on the main tree already. I guess if we cannot trust what is on the tree including retriggered jobs to show a trend, then we wouldn't be able to trust try. Do chime in if I am missing something outside of the once or twice a year a core infrastructure issue gives us false data. Thanks for bringing up your concerns so far- I look forward to making future regression bugs more reliable and trustworthy! On Wed, Aug 19, 2015 at 1:44 AM, L. David Baron dba...@dbaron.org wrote: 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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: recording use counters for web features
This is awesome - thanks Nathan! On Wed, Aug 19, 2015 at 8:35 AM, Nathan Froyd nfr...@mozilla.com wrote: Bug 968923, Implement some equivalent of Chrome's use counters, has landed on mozilla-central. We are now able to report statistics on whether individual documents use a given: - WebIDL method - WebIDL attribute (getters and setters reported separately) - CSS property - operation listed in dom/base/nsDeprecatedOperationList.h These statistics are reported through Telemetry. Deprecated operations are handled automatically. CSS properties require modifying dom/base/UseCounters.conf. WebIDL methods and attributes require modifying dom/base/UseCounters.conf and adding a [UseCounter] attribute to the appropriate entity in the corresponding WebIDL file. (Bug 1195959 tracks eliminating the WebIDL file modification, if you are curious.) Please see dom/base/UseCounters.conf for more information, and come find people in #content if you have questions. Thanks, -Nathan ___ 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
recording use counters for web features
Bug 968923, Implement some equivalent of Chrome's use counters, has landed on mozilla-central. We are now able to report statistics on whether individual documents use a given: - WebIDL method - WebIDL attribute (getters and setters reported separately) - CSS property - operation listed in dom/base/nsDeprecatedOperationList.h These statistics are reported through Telemetry. Deprecated operations are handled automatically. CSS properties require modifying dom/base/UseCounters.conf. WebIDL methods and attributes require modifying dom/base/UseCounters.conf and adding a [UseCounter] attribute to the appropriate entity in the corresponding WebIDL file. (Bug 1195959 tracks eliminating the WebIDL file modification, if you are curious.) Please see dom/base/UseCounters.conf for more information, and come find people in #content if you have questions. Thanks, -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
We have a static analysis for this right now:
https://dxr.mozilla.org/mozilla-central/source/build/clang-plugin/tests/TestNoRefcountedInsideLambdas.cpp
And there is potential for more static analyses if we decide that we
need them.
We also have bug 1157788 if we decide at some point that we want to
forbid default captures in lambdas and require explicitly listing the
capture variables.
- Michael
On 2015-08-19 8:35 AM, smaug wrote:
Hi bholley,
looks great, but a question
The example
mProducer-RequestFoo()
-Then(mThread, __func__,
[...] (ResolveType aVal) { ... },
[...] (RejectType aVal) { ... });
uses C++ lambdas. Do we have some static analysis or such in place to
protect that
lambdas don't refer to raw pointer variables in the scope
(especially raw pointer variables pointing to ref counted objects)?
Or does MozPromise have similar setup to bug 1153295 or what?
-Olli
On 08/19/2015 06:17 AM, Bobby Holley wrote:
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Selectors to Standardize
So after a nearly 2 year hiatus, I'm back to editing the Selectors 4 spec... I'm looking over the set of -moz- selectors http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPseudoClassList.h and wondering which ones we need to put on the standards track. (A) So far we already have on the standards track :-moz-only-whitespace as :blank http://www.w3.org/TR/selectors4/#the-blank-pseudo **Please, if you all have better name suggestions, we welcome them.** [ :blank imho sounds like a blank form element, which we might want a selector for in the future. :/ ] :-moz-any() as :matches() http://www.w3.org/TR/selectors4/#matches :-moz-any-link as :any-link http://www.w3.org/TR/selectors4/#the-any-link-pseudo :-moz-dir() as :dir() http://www.w3.org/TR/selectors4/#the-dir-pseudo Unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=859301 :-moz-read-only as :read-only ?? :-moz-read-write as :read-write ?? http://www.w3.org/TR/selectors4/#rw-pseudos These were pushed to CR in http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw along with the other form-state pseudos, so I'm not sure why they're still prefixed. Are there issues with these selectors that we need to sort out? :-moz-ui-invalid as :user-error http://www.w3.org/TR/selectors4/#user-pseudos :-moz-placeholder sortof as :placeholder-shown http://www.w3.org/TR/selectors4/#placeholder due to requests for ::placeholder as a pseudo-elements :-moz-drag-over as :drop or :drop() https://drafts.csswg.org/selectors-4/#drag-pseudos (B) Things I'm guessing we want to standardize: :-moz-ui-valid https://developer.mozilla.org/en-US/docs/Web/CSS/%3A-moz-ui-valid (C) Things I'm guessing we don't want to standardize: :-moz-empty-except-children-with-localname :-moz-bound-element :-moz-is-html :-moz-native-anonymous :-moz-system-metric :-moz-locale-dir :-moz-table-border-nonzero :-moz-devtools-highlighted :-moz-handler-clicktoplay :-moz-handler-playpreview :-moz-handler-vulnerable-updatable :-moz-handler-vulnerable-no-update :-moz-handler-disabled :-moz-handler-blocked :-moz-handler-crashed :-moz-math-increment-script-level :-moz-lw-theme :-moz-lwtheme-brighttext :-moz-lwtheme-darktext (D) Things I can't tell whether they're things we should standardize: :-moz-first-node :-moz-last-node :-moz-window-inactive :-moz-full-screen :-moz-full-screen-ancestor :-moz-focusring :-moz-broken :-moz-user-disabled :-moz-suppressed :-moz-loading :-moz-type-unsupported :-moz-type-unsupported-platform (E) Things I'm totally confused about: :-moz-meter-optimum :-moz-meter-sub-optimum :-moz-meter-sub-sub-optimum Seem to be explained by http://blog.teamtreehouse.com/use-meter-progress-elements except a lot of stuff mentioned there is not in the codebase?? My questions are 1. Is there anything above that's not on the correct list? 2. Can you help me sort list (D)? 3. Anyone have a better name for :blank? 4. Let me know what's up with :read-write and :read-only? 5. Please review the :drop spec for correctness/sanity~? https://drafts.csswg.org/selectors-4/#drag-pseudos 6. Ditto :user-error https://drafts.csswg.org/selectors-4/#user-pseudos 7. Any other comments? Thanks~ ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Tue, Aug 18, 2015 at 8:17 PM, Bobby Holley bobbyhol...@gmail.com wrote: 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 Does MozPromise have the same skipping the event loop behavior that JS promises have? Or is that limited just to StateMirroring? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: recording use counters for web features
On 8/19/15 11:35 AM, Nathan Froyd wrote: These statistics are reported through Telemetry. Have the in-tree docs been updated to document this? I don't recall being asked to review the final data collection proposal for this mechanism. In particular: * Will this only collect to the opt-in (prerelease) population, or does this also affect the release population? * This involves collecting a numerator and denominator as separate histograms, correct? * Is there reporting in place for this mechanism already? If not, who is going to write that? * How are we going to do data-collection reviews for additions, especially if the collection is added through WebIDL/UseCounters? * Is there a mechanism for auto-expiring data collection like there is for histograms? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Selectors to Standardize
On 2015-08-19 4:33 PM, fantasai wrote: (A) So far we already have on the standards track :-moz-only-whitespace as :blank http://www.w3.org/TR/selectors4/#the-blank-pseudo **Please, if you all have better name suggestions, we welcome them.** [ :blank imho sounds like a blank form element, which we might want a selector for in the future. :/ ] How about :whitespace-only? :-) :-moz-dir() as :dir() http://www.w3.org/TR/selectors4/#the-dir-pseudo Unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=859301 Do you know how similar :-moz-dir() and :dir() are? Based on a cursory look, it seems like they're fairly similar... :-moz-read-only as :read-only ?? :-moz-read-write as :read-write ?? http://www.w3.org/TR/selectors4/#rw-pseudos These were pushed to CR in http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw along with the other form-state pseudos, so I'm not sure why they're still prefixed. Are there issues with these selectors that we need to sort out? What does user alterable mean in the spec? Is input type=checkbox user alterable? What about input type=text readonly? What about input disabled? And so on... (I'd also ask about input readonly contenteditable too but I don't think there's agreement on what that even means...) Also, I can't tell whether these are supposed to be opposites in the spec. They are, in our implementation, I think. :-moz-placeholder sortof as :placeholder-shown http://www.w3.org/TR/selectors4/#placeholder due to requests for ::placeholder as a pseudo-elements According to the spec, this only applies to input, which is weird since textareas can also have a placeholder, and IIRC :-moz-placeholder does support that. (D) Things I can't tell whether they're things we should standardize: :-moz-first-node :-moz-last-node Why not? These sound useful to me... :-moz-focusring This seems useful as well. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: recording use counters for web features
On 2015-08-19 11:35 AM, Nathan Froyd wrote: Bug 968923, Implement some equivalent of Chrome's use counters, has landed on mozilla-central. Hurray! \o/ - WebIDL method - WebIDL attribute (getters and setters reported separately) - CSS property - operation listed in dom/base/nsDeprecatedOperationList.h Is there support for counting features that don't really fall into any of the above categories? Basically counting things programatically? These statistics are reported through Telemetry. Where does the data go? How can one view them? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Selectors to Standardize
On Thu, Aug 20, 2015 at 6:33 AM, fantasai fantasai.li...@inkedblade.net wrote: :-moz-full-screen :-moz-full-screen-ancestor :-moz-full-screen has been standardized as :fullscreen in Fullscreen API Standard [1], and that spec also introduces a new pseudo-element ::backdrop which has been implemented in Blink and Trident, and has a bug on our Bugzilla [2]. You may want to mention them in the Selectors 4 spec. [1] https://fullscreen.spec.whatwg.org/ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1064843 - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Telemetry Dashboards
Hello: Telemetry dashboards http://telemetry.mozilla.org/ received quite a few updates, and now needs some testing and feedback! These areas in particular have had significant changes: Evolution dashboard: Enumerated histograms. Boolean histograms. Switching between different histogram types. Export to JSON/CSV. Histogram dashboard: Single Boolean histograms (which should display as pie charts). The compare by functionality. Keyed histograms. Table view. Advanced settings, such as the sanitize and cumulative options. Other: Comments in the dashboards. Documentation quality and completeness. Telemetry for non-Desktop-Firefox products. Suitability for common workflows. To make trying things out easier, here are some example histograms: GC_MS - exponential histogram GC_MAX_PAUSE_MS - linear histogram BROWSER_IS_USER_DEFAULT - Boolean histogram GEOLOCATION_ERROR - flag histogram DEVICE_RESET_REASON - enumerated histogram UPDATE_CHECK_NO_UPDATE_EXTERNAL - count histogram Here's the issue tracker https://github.com/mozilla/telemetry-dashboard/issues for Telemetry dashboards. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote: Does MozPromise have the same skipping the event loop behavior that JS promises have? They do not. Or is that limited just to StateMirroring? Correct, as well as StateWatching. StateMirroring uses StableState to dispatch the atomic state updates, and StateWatching uses it to run notifications. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote: Does MozPromise have the same skipping the event loop behavior that JS promises have? They do not. Or is that limited just to StateMirroring? Correct, as well as StateWatching. StateMirroring uses StableState to dispatch the atomic state updates, and StateWatching uses it to run notifications. bholley Good. This should be clearly documented, as its a subtle but important distinction from JS promises, which people are likely to be familiar with. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 5:23 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey m...@kylehuey.com wrote: On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote: Does MozPromise have the same skipping the event loop behavior that JS promises have? They do not. Or is that limited just to StateMirroring? Correct, as well as StateWatching. StateMirroring uses StableState to dispatch the atomic state updates, and StateWatching uses it to run notifications. bholley Good. This should be clearly documented, as its a subtle but important distinction from JS promises, which people are likely to be familiar with. Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834 3 - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey m...@kylehuey.com wrote: On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey m...@kylehuey.com wrote: Does MozPromise have the same skipping the event loop behavior that JS promises have? They do not. Or is that limited just to StateMirroring? Correct, as well as StateWatching. StateMirroring uses StableState to dispatch the atomic state updates, and StateWatching uses it to run notifications. bholley Good. This should be clearly documented, as its a subtle but important distinction from JS promises, which people are likely to be familiar with. Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Tue, Aug 18, 2015, at 11:17 PM, Bobby Holley wrote: 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/. This looks fantastic! Having dealt with threading in C++ Gecko code in the past it's great to see tooling being built to alleviate some of the overhead and reduce the potential for bugs. Great work! -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
On Sun, Aug 9, 2015 at 9:59 PM, L. David Baron dba...@dbaron.org wrote: 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 This charter doesn't mention the WHATWG by name and merely says The Working Group will consider proposals for future specifications from Community Groups, encourage open participation from Community Group members, and keep coordination with relevant Community Groups, all within the bounds of the W3C patent policy and available resources. I'd like to know (preferably in the form of charter text) what the planned relationship with the WHATWG is supposed to be. Specifically, I don't expect this W3C group to be able to do a good job maintaining the features that are covered by actively maintained WHATWG specs except by having a fast, low-bureaucracy way to import spec text from the WHATWG. Having the W3C modularize (what year is this? 1999 all over again?) a WHATWG-originating spec with editorship Up for taking looks like the opposite of what's needed to have a fast, low-bureaucracy way to import spec text from the WHATWG. In general, modularizing the HTML spec for the sake of modularization seems useless busy-work. I think we should object to modularization for the sake of modularization. If there a bits that have an editor lined up and the browser vendors want to do non-maintenance development in the relevant area, then it might make sense to split out something on a case-by-case basis. Furthermore, merging HTML into WebApps seems low-risk only if there isn't much work to do around HTML. Activity around HTML seems to attract disruptions that would be unfortunate compared to WebApps going on operating without those disruptions. Therefore, it seems unwise to generate activity (such as pushing text around in order to modularize) around HTML needlessly if WebApps is to take over HTML. If an answer to the above is not already documented in public in a way that allows the W3C to be held to their word, I think we should ask about the above in our charter review comments. This charter includes the maintenance responsibility for a number of specs related to Widgets. Is this just a formality that pre-existing specs have to belong to *some* WG or is the group actually expected to spend time on maintaining Widgets? Does any vendor that can reasonably be expected to contribute staff time to the WG actually ship W3C Widgets or want to shift from whatever packaged Web app solution they do ship to W3C Widgets? It seems like a bad idea to put the group's time into Widgets if isn't the future we intend to pursue and, AFAICT, it isn't. 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. What's the rationale for this split? I realize that the Media TF of the HTML WG has been operating rather separately from the rest of the HTML WG, but if the PP is the main value proposition of the W3C, doesn't dividing work into smaller WGs undermine that value proposition? On Mon, Aug 10, 2015 at 1:28 PM, Gervase Markham g...@mozilla.org wrote: On 09/08/15 19:59, L. David Baron wrote: The Timed Media WG splits some of the media work that was happening in HTML (MSE, EME) into a separate group. Do we see a risk here that this group will become captured by the promoters of DRM, more than was possible when it was done in the HTML WG? I think moving EME into a group of its own would carry a major risk of the group finding other DRM things to work on in order to perpetuate its own existence. That's why I've cautioned against kicking EME out of the HTML WG. Since the proposed WG is not a DRM WG but the media WG with substantial non-DRM work to do, I'm somewhat less worried about this proposed WG than I would be about an EME-only WG. As noted above, the media TF has already been operating relatively separately. In that sense, this split doesn't involve much of a change in terms of who subscribes to which mailing list and who follows which meeting minutes. However, I don't see any benefit from having a Timed Media Working Group compared to having a Timed Media Task Force of the Web Platform Working Group and I can see potential for the separate working group to have a downside. The proposed Web Platform Working Group covers so many things that it's obvious that no single participant is going to participate in the development of all the deliverables. In that context, I think it's weird to split MSE, EME and the video/audio parts of HTML5 maintenance into a separate WG. I think it would be reasonable for us to record a comment along the lines of the above paragraph and have Media
Re: Intent to Ship: Updated third-party iframe storage behavior
On Tue, Aug 18, 2015 at 11:12 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: (We should probably rename that to Accept third-part[y] cookies and data:.) Should we? I was kind of hoping we could maintain the illusion that all storage is cookies since it would keep the UI simple. Users have enough trouble understanding cookies as it is. Though I suppose that once we add persistent storage that might get complicated. (Though calling that persistent cookies might actually be something that users understand more than anything else. May example.invalid store persistent cookies? (These cookies are only removed when you explicitly remove them.) Anyway, sorry to go off on a tangent, glad to see this is happening! -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decreasing quality?
On Wed, Aug 19, 2015 at 3:18 AM, Gavin Sharp ga...@gavinsharp.com wrote: It's possible this bug was being confused with bug 1195030. That seems likely, yes. Being responsible for this particular regression, I can say that neither is it at all related to the other bugs mentioned, nor can it reasonably be interpreted as a sign of decreasing attention to quality: the patch I landed triggered a preexisting bug in a way that was pretty much unforeseeable and, because we didn't know about it, wasn't covered by our test suite. While the result was particularly bad - and I apologize for that - I don't see what I could've done better to catch it before landing. Also keep in mind that we have hundreds of CPU hours of automated tests running before changes land in mozilla-central and can become part of Nightly. If you add new functionality without proper tests, shame on you; if you did your due diligence and still have the bad luck of introducing a new bug - be lucky that we have the Nightly channel. (From four or so years of experience running Nightly as my main browser, I can say that every now and again things seem to come to a head, with multiple annoying issues occurring in a short time frame. I'm pretty sure that that's always [or almost always] purely by chance, and reading too much into it isn't warranted. Neither does it make sense to pat ourselves on the shoulder too much in the stretches of unusual stability we also have on the Nightly channel.) till 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Selection Events
On Tue, Aug 18, 2015 at 6:21 PM, Michael Layzell mich...@thelayzells.com wrote: 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 Listeners for these new events should be visible in the inspector [1] and debugger [2] and the user should be able to break on them. I don't expect any devtools changes will be needed to make this work, but I'm mentioning it in order to be tested and verified. Thanks, Panos [1]: https://developer.mozilla.org/docs/Tools/Page_Inspector/How_to/Examine_event_listeners [2]: https://developer.mozilla.org/docs/Tools/Debugger/How_to/Break_on_a_DOM_event ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Decreasing quality?
I fondly remember the days when Nightly was sporting golden tabs on OSX; it’s part of the joy running the cutting edge! Cheers, Mike. ___ 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 7:47 PM, Jonas Sicking wrote: 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? That's a great point! I commented on the bug. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
