Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

On Fri, Mar 15, 2019 at 10:35 AM devsnek wrote: > If this is how you feel, encourage Google to fix the problem. This isn't > Firefox's fault, Firefox is doing the right thing by supporting > standardized APIs instead of "whatever Google uses". It's incredibly > frustrating and demoralizing to

Re: Tagged pointers

On Fri, Jul 13, 2018 at 11:40 AM, Steve Fink wrote: > On 07/12/2018 04:27 PM, Cameron McCormack wrote: > >> On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote: >> >>> I actually have a patch sitting around with helpers to make it super >>> easy to >>> use smart pointers as tagged pointers :)

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

On Thu, Jul 12, 2018 at 11:25 AM, Karl Tomlinson wrote: > Would it be easier to answer the opposite question? What should > not run in a shared process? JS is a given. Others? > Currently when an exploitable bug is found in content process code, attackers use JS to weaponize it with an

Re: OrangeFactor/Intermittent Failures View Update

Thank you very very much for making this information public again! Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

I read the threads you referenced and the latest spec, and I think you're absolutely right about everything :-). On Fri, May 4, 2018 at 10:21 AM, Karl Tomlinson wrote: > Thank you for taking a look, Boris. I'm quite unclear how any of > the changes proposed in the [[March

Re: Intent to implement: AudioWorklet

On Wed, May 2, 2018 at 9:21 PM, Karl Tomlinson wrote: > It seems that Chrome works around this by choosing to garbage > collect input nodes even when their presence is specified to > require (observable) AudioWorkletProcessor.process() calls. > This garbage collection is

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Tue, Mar 20, 2018 at 3:02 AM, Henri Sivonen wrote: > I understand that the goal is better privacy. But it's likely that > people get outraged if a browser sends information about what is > browser to an off-path destination without explicit consent regardless > of

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On Fri, Mar 9, 2018 at 2:26 PM, Bobby Holley wrote: > I was just measuring the methods themselves via |nm --print-size|. There > might be additional per-method overhead in the data segment for the > associated static tables, but the baseline size for the code itself >

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

On Tue, Dec 5, 2017 at 2:00 PM, Gregory Szorc wrote: > Many programming languages paper over these subtle differences leading to > badness. For example, the preferred path APIs for Python and Rust assume > paths are Unicode (they have their own logic to perform

Re: Intent to unship: mozmm CSS unit.

I thought there was also a legitimate use-case for displaying content "life size", e.g. if you wanted to draw a ruler on a tablet. But if the CSSWG doesn't agree after all this time, just drop it I guess. (Though I think there's something slightly broken about how Web developer needs are

Re: Website memory leaks

Now that I'm writing a Web app for real, I realize just how easy it is to accidentally leak :-(. It would be useful, or at least cool, to be able to show users and developers a graph of memory usage over time, one line per tab. You could limit this to just show the top N memory-hungry tabs. A UI

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

BTW can someone forward this entire thread to their friends at AMD so AMD will fix their CPUs to run rr? They're tantalizingly close :-/. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

On Fri, Oct 27, 2017 at 2:34 AM, Henri Sivonen wrote: > And the downsides don't even end there. rr didn't work. Plus other > stuff not worth mentioning here. > Turns out that rr not working with Nvidia on Ubuntu 17.10 was actually an rr issue triggered by the Ubuntu libc

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Tue, Sep 12, 2017 at 11:38 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > I don't think so, that data already exists and is query-able from > ActiveData: > https://activedata.allizom.org/tools/query.html#query_id=8pDOpeni That query tells you about disabled tests, but doesn't

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Sat, Sep 9, 2017 at 11:09 AM, Gregory Szorc wrote: > Is it worthwhile to define and use a richer test manifest "schema" that > will facilitate querying and building dashboards so we have better > visibility into disabled tests? > It would be great if there was a way to run

Re: Debugging Firefox e10s with rr?

On Wed, Aug 30, 2017 at 1:16 AM, Kartikaya Gupta wrote: > rr works just fine with multiple processes. Once you have a recording > you can use `rr ps` to show all the process that were recorded and `rr > replay -p ` to attach to a particular process. You can combine -p > with

Re: disabled non-e10s tests on trunk

On Wed, Aug 9, 2017 at 9:31 AM, Boris Zbarsky wrote: Something as simple as "debug something that happens during pageload" is > currently fairly rocket science to do in e10s mode; doubly so in > e10s-multi. I haven't seen any concrete proposals for improving this rr

Re: Extensions and Gecko specific APIs

Experience from Web content standards probably informs the situation here... On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swan wrote: > For handling cross-platform versus Firefox-specific APIs, I don't think the > right outcome is perfectly clear. Of course we should learn from

Re: Extensions and Gecko specific APIs

On Wed, Jul 26, 2017 at 11:07 AM, wrote: > I think that such an API could be spec'd such that it is portable, with > the output being flexible enough that we can put Mozilla-specific > information in there. E.g.: A fixed API to get the data, and a minimal > structure for

Re: Rationalising Linux audio backend support

On Fri, Mar 31, 2017 at 7:45 PM, wrote: > Good choice from Ubuntu. In the meantime, I have run PA->aloop->JACK. Now I > am back with aloop->JACK. PA is removed from the system (and hopefully, I > will never need it again). I turned on telemetry for now, but will turn it

Re: Faster gecko builds with IceCC on Mac and Linux

On Fri, Mar 24, 2017 at 1:12 PM, Ehsan Akhgari wrote: > On Thu, Mar 23, 2017 at 7:51 PM, Jeff Gilbert wrote: > >> I'm interested to find out how the new Ryzen chips do. It should fit >> their niche well. I have one at home now, so I'll test when I

Re: Should &&/|| really be at the end of lines?

On Fri, Feb 17, 2017 at 12:25 PM, L. David Baron wrote: > Using clang-format on the entire tree has the massive value of: > > * reviewers not needing to point out whitespace and indentation issues > > * reduced friction for new contributors (being able to use a tool >

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 11:41 AM, Sebastian Zartner < sebastianzart...@gmail.com> wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=740910 My comments in that bug still apply. Ellipsizing in the centre when the line contains more than just a single text node is really hard. Rob -- lbir

Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

On Thu, Sep 22, 2016 at 10:47 AM, Ehsan Akhgari wrote: > My point was more about whether there's something useful that can be > done with partially downloaded files other than media files. Not all > file formats lend themselves to be used before the full file is >

Re: netwerk and media experts; feedback requests for background upload/download WebAPI video download use-case

On Thu, Sep 8, 2016 at 5:45 AM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > A motivating use-case is for a site that wants to download movies/podcasts > in the background and keep them around for offline purposes. Once the file > is downloaded, it seems clear that the

Re: MXR permanently offline, please transition to DXR

In theory responses 301 and 308 mean "permanent redirect" so the browser could do that for those responses. In practice you'd need a lot of data to convince yourself that Web developers haven't screwed this up too badly. Maybe 308, being newer, is not compromised... Rob -- lbir ye,ea

Re: The Whiteboard Tag Amnesty

On Thu, Jun 9, 2016 at 9:31 PM, Gijs Kruitbosch wrote: > I'm confused. How are keywords not permissionless? He meant that adding a new keyword requires permission. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor

Updated chaos mode on rr master

Last night I landed some changes to improve chaos mode: http://robert.ocallahan.org/2016/02/deeper-into-chaos.html It should be significantly improved. Bugs found in chaos mode before might take longer to reproduce now, but should still be reproducible. Some bugs it couldn't find before are now

Re: rr chaos mode update

On Mon, Feb 15, 2016 at 10:58 PM, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote: > On 15/02/2016 05:16, Robert O'Callahan wrote: > >> At this point the limiting factor is getting developers to actually debug >> and fix recorded test failures. >> > > We

Re: rr chaos mode update

On Mon, Feb 15, 2016 at 7:21 PM, Mike Hommey wrote: > Relatedly, roc, is it possible to replay, on a different host, with > possibly a different CPU, a record that would have been taken on the > cloud? Does using a VM make it possible? If yes, having "the cloud" (or > a set of

Re: rr chaos mode update

On Mon, Feb 15, 2016 at 6:26 PM, Kyle Huey wrote: > > FWIW, every failure that I've debugged to completion so far has been a bug > in the test (although I have two fatal assertion bugs I'm working through > that will obviously be flaws in Gecko). I think one of the things we

rr chaos mode update

Over the last few days we have had a lot of positive experiences reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's been able to reproduce every single bug he tried with enough machine time thrown at it. At this point the limiting factor is getting developers to actually debug

Re: Using rr chaos mode to find intermittent bugs

On Fri, Feb 12, 2016 at 8:39 AM, Kyle Huey <m...@kylehuey.com> wrote: > On Thu, Feb 11, 2016 at 11:35 AM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > >> On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron < >> nicolas.b.pier...@mozilla.com> wrote:

Re: Using rr chaos mode to find intermittent bugs

On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > On 02/10/2016 08:04 PM, Robert O'Callahan wrote: > >> Background: >> http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html >> >> I just landed on rr ma

Using rr chaos mode to find intermittent bugs

Background: http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html I just landed on rr master support for a "-h" option which enables a chaos mode for rr recording. This is designed to help reproduce intermittent test failures under rr. We already have a few reports of people using

Re: Using rr chaos mode to find intermittent bugs

On Thu, Feb 11, 2016 at 9:32 AM, Ted Mielczarek wrote: > BenWa tried doing some work on this but kept getting hung up > on hitting test failures unrelated to the ones we see in production, possibly due to environment issues. > Yes. In this vein, it's possible that in some

Re: Using rr chaos mode to find intermittent bugs

rr should work fine with c-c xpcshell tests (and most other Linux programs). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

On Fri, Jan 15, 2016 at 12:01 PM, Nick Fitzgerald wrote: > Console, debugger, performance: these panels are ​a clear "always show" to > me. The web audio tool is very niche and so I don't think it would make > sense to show it by default. The memory tool falls in between

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Sounds good to me too. What's blocking us from enabling by default? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm

Re: wptview [Re: e10s]

On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg wrote: > What are the implications of this? > > The web-platform tests are pass/fail, right? So is it a bug if they pass > but have different behaviors in e10s and non-e10s mode? > Yeah, I'm confused. If a wpt test

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Fri, Jan 8, 2016 at 11:08 AM, Jeff Gilbert wrote: > On Wed, Jan 6, 2016 at 8:07 PM, Luke Wagner wrote: > > FWIW, I was wondering if we could go a step further and allow > > (optional) user interaction with the rendered DOM elements. That way > >

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Thu, Jan 7, 2016 at 8:46 PM, Anne van Kesteren wrote: > At least enforcing CORS-same-origin would be somewhat trivial from a > specification perspective since all fetches go through Fetch. Limiting > plugins and other affected features would be some added conditionals > here

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Fri, Jan 8, 2016 at 2:36 PM, Jeff Gilbert wrote: > I think rather we should aim to provide a way for the application to > implement custom remapping of events. A simple version of this is > allowing the app to synthesize enough of the inputs to virtually use > our

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Fri, Jan 8, 2016 at 9:58 AM, wrote: > There are two use cases for this functionality needed by the WebVR team. > > The one needed earliest is to implement HUD interfaces and dialogues. In > this case, we will only be using this API from chrome privileged code. >

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Wed, Jan 6, 2016 at 9:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Tue, Jan 5, 2016 at 10:18 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > That's an option, but it's a very large problem that's very difficult to > > get right. And ther

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Wed, Jan 6, 2016 at 9:45 AM, Kearwood "Kip" Gilbert wrote: > If it is not feasible to prevent variation in timing or to otherwise > prevent content from determining the content of the texture, perhaps > another approach would be to require all elements to be sanitized

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 11:50 AM, Jeff Gilbert wrote: > I think that it would be most efficient just to have a meeting about > these topics, instead of iterating slower via email. > FWIW I feel like it's more efficient to use email, especially if not all issues can be

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking wrote: > A big problem is sticking HTML/CSS content into WebGL is that WebGL > effectively enables reading pixel data through custom shaders and > timing attacks. > If you read

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > Yeah, we have a public mailing list: public_we...@khronos.org > As with anything WebGL related, you can also just talk to me about it. > I don't want to step on whatever you were thinking of changing, but I'm happy to

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert < kgilb...@mozilla.com> wrote: > In WebVR, we often present UI as a Head's Up Display (HUD) that floats > in front of the user. Additionally, we often wish to show 2d graphics, > video, and CSS animations as a texture in 3d scenes.

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > > Essentially, we would extend the same API but allow the WDTStream > >> interface to apply to more HTML elements, not just HTMLCanvasElement, > >> HTMLImageElement, or HTMLVideoElement. > >> > >> We would also need to

Re: WebUSB

On Mon, Dec 14, 2015 at 11:09 PM, Eric Rescorla wrote: > This is certainly something one could consider, but it it seems like it > confers a major > advantage on the vendor vis-a-vis everyone else. If we're going to have an > add-on > mechanism, I don't see why vendors can't use

Re: WebUSB

On Mon, Dec 14, 2015 at 9:29 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson <m...@mozilla.com> wrote: > >> On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> > On

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On Sun, Dec 13, 2015 at 2:28 PM, Bobby Holley wrote: > I don't know why we would allow there to be a long gap between (a) and (b). > Maintaining/supporting two sets of the same code is costly. So if we get > the rust code working and shipping on all platforms, I can't

Re: WebUSB

On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla wrote: > (4) Have the APIs hidden behind access controls that need to be enabled by > an extension > (but a trivial one). Perhaps you think this is #2. > I realized I don't understand exactly what this means. I assume "extension"

Re: WebUSB

On Thu, Dec 3, 2015 at 11:48 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > 1) What I suggested: Whitelist vendor origins for access to their devices > > and have vendor-hosted pages

Re: WebUSB

On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > >> There are three possible approaches I can see to expose USB devices to >> third-party applications:

Re: WebUSB

On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla wrote: > > Sure. Conversely, I don't find myself convinced by your position. > > Would be happy to talk about this live if you think that's useful. > Probably not ... these are judgement calls that are difficult to resolve. Rob --

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On Tue, Dec 1, 2015 at 4:26 AM, Ehsan Akhgari wrote: Should we finally bite the bullet and force a flush in reftests/crashtests? You mean force a flush in the load event handler in the test harness, before the test's load event handler runs? > After thinking about

Re: APZ enabled on Fennec nightly

Fantastic!!! Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh

Why do we flush layout in nsDocumentViewer::LoadComplete?

We've always done it, but I can't think of any good reasons. I seem to recall that one reason was we want onload to be usable to measure page-load-and-layout time, but that would be a bad reason. If we didn't do that, we could run onload scripts earlier and maybe do less layout if they update the

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 11/26/15 9:24 PM, Robert O'Callahan wrote: > >> We've always done it, but I can't think of any good reasons. >> > > I've tried to fix this in the past and ran into two problems. > > T

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

On Fri, Nov 27, 2015 at 8:29 PM, Xidorn Quan wrote: > Our tests relying on this is probably because certain bugs are only > detectable when we apply content/style change after a layout flush. > That's right. This change is likely to hide more bugs than it causes. Rob --

Re: Single- vs. double-precision FP in gfx types

On Wed, Nov 25, 2015 at 11:59 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > >> > >> One major remaining Moz2Dification step is the conversion of thebes > >

Re: Single- vs. double-precision FP in gfx types

On Wed, Nov 25, 2015 at 3:24 PM, L. David Baron wrote: > On Tuesday 2015-11-24 18:21 -0800, L. David Baron wrote: > > Presumably it's equally important to replace the remaining > > nsRenderingContext usage with DrawTarget? > > > > (nsRenderingContext was the previous API

Re: Single- vs. double-precision FP in gfx types

On Tue, Nov 24, 2015 at 4:45 PM, Nicholas Nethercote wrote: > One major remaining Moz2Dification step is the conversion of thebes > types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D > equivalents. But this is largely blocked by the fact that the

Re: Intent to ship: Service Workers with FetchEvent

On Sat, Nov 21, 2015 at 9:42 AM, Ben Kelly wrote: > I think the best thing we can do right now is get a second implementation > into wide circulation. This will highlight compat issues yes, but also > help avoid baking chrome specific behavior into all the sites using

Re: How can I find out when a background image is loaded?

On Sat, Nov 7, 2015 at 9:05 PM, Geoff Lankow wrote: > It's a lot harder to do what "background-size: cover" does, with an . How about object-fit:cover? https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr

Re: Date, time, week, month and datetime attributes in the in Firefox

html5test.com gives points for supporting those types. That alone doesn't justifying doing them, but it's not nothing either. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l

Re: Intent to implement and ship: HTMLElement.innerText

On Tue, Oct 20, 2015 at 1:18 AM, Ms2ger wrote: > Please submit tests to web-platform-tests and create a pull request to > the HTML standard. > Will do, after a decent interval to collect feedback. I wrote web-platform-tests to land with our implementation. Rob -- lbir ye,ea

Intent to implement and ship: HTMLElement.innerText

https://bugzilla.mozilla.org/show_bug.cgi?id=264412 Webkit, Blink and Trident have been shipping this for years without a spec and with poor interop. We held off on implementing it since you can polyfill a better implementation in JS without much difficulty, but we have to implement something for

Re: Intent to unship: jar: URIs from content

On Sat, Oct 17, 2015 at 6:13 AM, Gregory Szorc <g...@mozilla.com> wrote: > On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > >> I'm sad that I won't be able to use jar: URLs to load testcases in ZIP >> files uploaded to Bugzill

Re: Is APZ meant to be a permanent part of the platform?

On Mon, Oct 5, 2015 at 7:20 AM, Marcus Cavanaugh wrote: > APZ is wonderful, making the web feel smooth when a page's demands would > otherwise cause jank. In many cases, it's the *only* reason we're able to > create decent experiences today, particularly on mobile. > > It does,

Re: NPAPI plug-in use case: live video broadcast

On Sat, Sep 26, 2015 at 10:20 AM, wrote: > MSE is playback only, so no option for live broadcast. > What do you mean? There doesn't seem to be any reason why MSE can't do live broadcast. If you're using HLS, you can use MSE. https://github.com/dailymotion/hls.js > WebRTC

Re: About static analyzers on some various projects

On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari wrote: > On 2015-09-25 12:01 PM, Justin Dolske wrote: > >> At Mozilla, it seems like previous discussions on this kind of thing >> (style and warnings come to mind) have dealt with this at a >> file/directory/module level...

Re: About static analyzers on some various projects

On Sat, Sep 26, 2015 at 1:46 AM, Ehsan Akhgari wrote: > Our static analysis builds can be easily triggered from the try server > (although I have been unable to get anyone interested to fix bug 1116518 to > make those builds happen on the try server by default, which

Re: About static analyzers on some various projects

Why not make scan-builds and infer results public? Those are public tools so we should assume black-hats already have the resutls. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto

Re: Considering dropping Talos support for Linux32

On Fri, Sep 25, 2015 at 1:40 PM, wrote: > Thanks for reading and fixing Performance regressions when they show up in > your patches! > FWIW I agree that Talos results for Linux32 are unimportant. Even if there was a Linux-32-only regression, I don't think it'd be worth our

Re: About static analyzers on some various projects

On Fri, Sep 25, 2015 at 5:41 AM, Sylvestre Ledru wrote: > Any questions, comments? > This whitepaper on Infer is an interesting read:

Editbugs access for Chromium bug tracking

Courtesy of Rick Byers, who is promoting an increased focus on interop within Blink/Chromium, it's now possible for "trusted" Mozilla developers to get editbugs access to Chromium's bug tracker, initially just a small number of us. I just got granted access. So if you want access, let me know and

Re: Intent to ship: Canvas CaptureStream

On Fri, Sep 18, 2015 at 9:02 PM, Ms2ger wrote: > That bug does not seem to support the claim that they intend to ship > this feature. No intent-to-ship is mentioned, and it appears the > intent-to-implement has not been sent. > Here's evidence they intend to implement:

Re: Proposal: revisit and implement navigator.hardwareConcurrency

Yes, I think we should do this. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa

Re: How would you like to spell check this?

On Wed, Sep 2, 2015 at 6:41 PM, Jörg Knobloch wrote: > I would like to hear a good argument why this confusing behaviour should > be maintained. I don't consider the following a good argument (quote): > "Believe me when I say that *every single time* we have tried to "fix" >

Re: Allowing web apps to delay layout/rendering on startup

On Sun, Aug 2, 2015 at 11:58 AM, Zibi Braniecki zbigniew.branie...@gmail.com wrote: So maybe we would need another event that the website fires to indicate when it for paint/cache/screenshot. Assuming pages have an easy way to block the 'load' event until they're ready, can this just be the

Re: Allowing web apps to delay layout/rendering on startup

On Mon, Aug 3, 2015 at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: The need is not for an event, no? But rather for an API which allows the page to tell the browser that it's ready for initial rendering? Right. Which gets turned into an event that's sent to the browser. Rob -- lbir ye,ea

Re: layers.async-pan-zoom.enabled amazing performance increase

On Thu, Jul 30, 2015 at 9:13 PM, webko...@gmail.com wrote: Hi, i enabled layers.async-pan-zoom.enabled in firefox on Mac OSX Yosemite, and noticed dramatic performance increase. Great! Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a

Re: Implement Fetch?

On Fri, Jul 24, 2015 at 3:41 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/23/15 11:36 AM, Anne van Kesteren wrote: By SVG resource document do you mean one that is fetched as an image? In Gecko's case I specifically mean one fetched as a paint server. It's somewhat of an implementation

Re: GTK3 linux builds

On Wed, Jul 22, 2015 at 10:59 AM, Mike Hommey m...@glandium.org wrote: Done. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inboundrevision=939320b957c5 Excellent! - deciding how to handle the situation for people who don't have gtk3 installed on their system. Currently, firefox

Re: GTK3 linux builds

On Tue, Jul 21, 2015 at 7:04 PM, Mike Hommey m...@glandium.org wrote: On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote: On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey m...@glandium.org wrote: There are a few remaining perma reds and oranges, FWIW. Which ones? I don't see

Re: Intent to implement HTMLMediaElement.srcObject partially

On Mon, Jul 20, 2015 at 6:33 PM, Jonas Sicking jo...@sicking.cc wrote: Good point. We also need to call URL.revokeObjectURL(this.mOldObjectURL); in the .src setter and in the dtor. OK, but we still leak if someone saves a reference to the HTMLMediaElement as an expando property of the

Re: Intent to implement HTMLMediaElement.srcObject partially

On Thu, Jul 16, 2015 at 5:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey j...@mozilla.com wrote: This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. For what it's worth, I think

Re: GTK3 linux builds

Jeff, does Flash with with GTK3 builds? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer

Re: Intent to implement W3C Manifest for web application

On Thu, Jul 16, 2015 at 4:54 AM, Martin Thomson m...@mozilla.com wrote: On Wed, Jul 15, 2015 at 4:12 AM, mar...@marcosc.com wrote: some people believe that web applications should be installable I don't subscribe to that theory. The web is comprised of pages, not apps. (I mostly agree

Re: Intent to implement HTMLMediaElement.srcObject partially

Hooray! Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On Wed, Jul 15, 2015 at 3:40 AM, Joshua Cranmer  pidgeo...@gmail.com wrote: The biggest problem here is that WebIDL and XPIDL codegen are heavily geared towards camelCase names, as the IDL convention is camelCase. C++ names matching WebIDL (or spec names in general) has value. We've gotten

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Wed, Jul 15, 2015 at 2:55 AM, Thomas Zimmermann tzimmerm...@mozilla.com wrote: The discussion has a number of good points in favor of using 'a', but I missed convincing arguments in favor of not using 'a'. Are there any? I don't consider I don't get what 'a' is good for a convincing

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 3:26 PM, Mike Hommey m...@glandium.org wrote: The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] FWIW many coding styles do

Re: Intent to ship: vertical text support (CSS writing-mode and related properties)

So tables and flexbox will be fixed in 41 too? Congratulations on nearing the end of such a long and difficult project! Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

Will it ever be possible to eliminate TemporaryRef and use moves instead? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo

Re: Revisiting modelines in source files

On Sat, Jun 20, 2015 at 3:27 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I also think automated tools probably won't get us meeting the style guide perfectly -- e.g. the aforementioned line-length wrapping, and can they ensure CamelCaps() function names and aFoo/mFoo/gFoo/sFoo

  1   2   3   4   >