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

[Robert O'Callahan]

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 see web standards being undermined in this
> way.
>

Mozilla people know this and I'm sure they've made every effort to
"encourage" Google. It's up to you, and whoever else you can organize, to
exert whatever additional pressure you can on Google (on this and similar
issues).

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tagged pointers

[Robert O'Callahan]

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 :) I never wound up putting it up
>>> for
>>> review, since my original use case went away, but it you can think of any
>>> specific cases where it would be useful, I'd be happy to try and get it
>>> landed.
>>>
>> Speaking of tagged pointers, I've used lower one or two bits for tagging
>> a number of times, but I've never tried packing things into the high bits
>> of a 64 bit pointer.  Is that inadvisable for any reason?  How many bits
>> can I use, given the 64 bit platforms we need to support?
>>
>
> JS::Value makes use of this. We preserve the bottom 47 bits, but that's
> starting to be problematic as some systems want 48. So, stashing stuff into
> the high 16 bits is pretty safe!
>

57-bit address space support is coming for x86-64.

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 arsenal of known techniques (e.g.
heap spraying and shaping). An important question is whether, assuming a
similar bug were found in a shared non-content process, how difficult would
it be for content JS to apply those techniques remotely across the process
boundary? That would be a pretty interesting problem for security
researchers to work on.

Use of system font, graphics, or audio servers is in a similar bucket I
> guess.
>

Taking control of an audio server would let you listen into phone calls,
which seems interesting.

Another question is whether you can exfiltrate cross-origin data by
performing side-channel attacks against those shared processes. You
probably need to assume that Spectre-ish attacks will be blocked at process
boundaries by hardware/OS mitigations, but there could be
browser-implementation-specific timing attacks etc. E.g. do IPDL IDs
exposed to content processes leak useful information about the activities
of other processes? Of course there are cross-origin timing-based
information leaks that are already known and somewhat unfixable :-(.

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OrangeFactor/Intermittent Failures View Update

[Robert O'Callahan]

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 F2F resolution]] comment would
> resolve the issue, and so I expect not.
>
> [[March F2F resolution]]
> https://github.com/WebAudio/web-audio-api/issues/1471#
> issuecomment-376223916


I wonder what that resolution entails since the spec changes haven't
happened yet.

However, it sounds like it's heading in the wrong direction. Rather than
trying to fix the description of AudioNode lifetimes, the entire section
should be deleted.

He does seem to have misunderstood that there is a problem to fix.
> But I assume the way forward here is to help the WG find a
> solution that works.  What is the advantage of explaining the
> situation to Alex?
>

AIUI If you can't convince someone on the WG that there is problem to fix,
but you can convince someone on the TAG, then they can require the WG to
fix it.

I'm happy to query the F2F resolution, but I wonder which is the
> best way to resolve this.
>
> Is having web specifications try to describe object lifetimes
> helpful, or is it just over-prescribing?
>

I think it's very dangerous. If those descriptions are normative then it's
easy to accidentally make GC observable. If they're not normative then they
confuse implementors and users into accidentally treating them as normative.

Should specifications instead just focus on observable behavior,
> and leave it to implementations to optimize and to reclaim
> resources that are no longer required?
>

Yes. People need to understand that GC is purely an optimization.

Perhaps it would be best to just have an informative section
> explaining design decisions made for the sake of making resource
> reclamation possible, such as lack of graph introspection.  Perhaps
> it would also be helpful to have some informative reminders to
> implementations re what GC must not affect.
>

Yes.


> If the whole normative AudioNode lifetime section were dropped
> then this would clearly be an implementation issue rather than a
> spec issue.
>

Yes!

Maybe I can help by writing a blog post or something...

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: AudioWorklet

[Robert O'Callahan]

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 performed in a way that causes the
> process() calls to be halted (which stops sound production), and
> so the AudioWorkletProcessor can subsequently also be garbage
> collected if there are no rooted references, as usual.
>
> Having the behavior of AudioWorkletProcess depend on whether or
> not the client maintains references to input nodes is not
> something I'd like to implement.  It would be comparable to an
> audio element stopping playback at a time when an implementation
> chooses to perform garbage collection after the client has removed
> its last reference.  It is contrary to [[TAG design principles]].
> The Chrome approach seems to be based on a different understanding
> of [[AudioNode Lifetime]].
>

Making GC timing observable is a big, big problem. I hope you escalate this
aggressively with the Chrome team.

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 intention, nightliness or promises the destination has made.
>

Today the Mozilla blog says:

> At Mozilla, our approach to data is simple: no surprises, and user choice
is critical.
https://blog.mozilla.org/blog/2018/03/20/mozilla-statement-petition-facebook-cambridge-analytica/

It would be unfortunate to undermine that message in the current
environment.

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
> (argument conversion, error handling, etc) is nontrivial.
>

It might be worth measuring how that translates to installer code. One
might hope that all that repetitive boilerplate code compresses well (or
can be made to).

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
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 encoding/decoding
> behind the scenes and depending on settings, run-time failures or data loss
> can occur).


I don't think that's true for Rust. Rust's `Path` and `PathBuf` are the
preferred data types and wrap an underlying `OsStr`/`OsString`, which
claims to be able to represent any path for the target platform. On Linux
an `OsString` is just an array of bytes with no specified encoding, and on
Windows it appears to be an array of WTF-8 bytes, so that claim seems valid.

Of course PathBuf isn't exactly what you want for an application like
Mercurial, since there I guess you want a type that represents any path
from any platform, including platforms other than the target platform...

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: mozmm CSS unit.

[Robert O'Callahan]

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 bubbling up to WGs. For example GeometryUtils hasn't been
implemented by other browsers, who apparently detect no pressure from Web
developers to solve the use-cases it solves, e.g. computing px offsets
between arbitrary elements even if they're in a DOM subtree with a scale
transform. Yet I ran into that problem pretty quickly while coding a Web
UI. Maybe I'm just strange...)

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Website memory leaks

[Robert O'Callahan]

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 intervention like the slow-script notification seems plausible. You
can probably come up with pretty good heuristics for identifying leaking
tabs. One signal would be steady memory growth during times without user
interaction. Then you can show the memory growth graph and offer to reload
the tab.

When devtools are open you could be a lot more aggressive about warning
developers if you think their app might be leaking. Actually, as an aside,
there's a more general devtools request here: when I'm using my own app,
even when devtools are not open, I'd like to be notified of JS errors and
other serious issues. One way to do this would be that if I ever open
devtools on a site, then set a "warn on errors" flag for that site, and
ensure the warnings offer a "stop warning me" button.

There's a lot of research literature on tools for tracking down leaks using
periodic heap snapshots and other techniques. Most of it's probably junk
but it's worth consulting. Nick Mitchell and Gary Sevitsky did some good
work.

IIRC you already have a "this is probably an ad" URL blacklist, so bounding
the memory usage of those IFRAMEs, freezing them when they reach it, sounds
good. You shouldn't need process isolation for IFRAMEs for 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 rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 upgrade, not Nvidia's fault. I just
fixed it in rr master. We'll do an rr release soon, because the libc update
required a number of rr fixes.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 know about *why* a
test was disabled. E.g. you can't distinguish tests disabled because
they're not expected to work on some (or all) platforms from tests that
were disabled for intermittent failures that should, in principle, be fixed.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 all tests that were disabled
due to intermittent failures. You could then use rr, and better tools we're
building based on rr, to catch some subset of those failures and resolve
them.

But given that information doesn't exist for all the tests disabled so far
(many tests over many years), it hardly seems worth starting now. Hopefully
it can be deduced by looking up bug metadata associated with commits that
disabled tests.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Debugging Firefox e10s with rr?

[Robert O'Callahan]

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 -g as Cameron mentioned to jump to a particular point in a
> particular process' lifetime.
>

You can also do "rr replay -p plugin-container" to debug the first
plugin-container process.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Robert O'Callahan]

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 makes it fairly easy on Linux. On Mac and Windows ... yeah.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Robert O'Callahan]

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 how
> web-exposed APIs evolved and avoid the need for the browser extensions
> equivalent of jquery.  On the other hand, browser extensions by their
> nature work with features that are not standardized and that differ from
> browser to browser.  For instance, we have WebExtensions APIs for working
> with containers.  There's no doubt in my mind that we should have this API
> but of course extensions that use it won't work in other browsers.  Maybe
> in this case some sort of moz- prefix would be appropriate but its not hard
> to come up with murkier examples.


You probably don't want to use a prefix there. What if some other browser
decided to support containers? Then they'd want to implement your API and
having it be prefixed is then horrible for everyone.

What about the tabs API?  It is
> currently supported in Firefox, Chrome, Edge, and Opera.  But what if one
> of the non-tab-based-browser-ui projects takes off and wants to support
> browser extensions?  If they simply don't support the tabs API then how
> should the API be named to indicate to extension developers that it isn't
> universally available?
>

It's probably best to be pessimistic about extension developers' behaviour.
In practice the tabs API, or any other API, is either universally present
in the browsers they care about, or it is not. In the former case they will
rely on it explicitly or implicitly (e.g. by having untested fallback code
paths that don't work). In the latter case they will discover the problem
and fix it. Either way naming probably doesn't help much.

Developers of your putative non-tabbed browser would have to recognize the
situation and decide what's best for them. If there are lots of extensions
that rely on the tabs API, maybe the browser developers would have to put
in some stub implementation that tries to do something sensible.

One thing that might help (and maybe you already have this?) is to have the
extension manifest contain a whitelist of the set of APIs the extension
requires. That would allow easy filtering to determine which extensions are
supported by a browser.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extensions and Gecko specific APIs

[Robert O'Callahan]

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 the output, but say, each log message could have a free-form
> 'data' json object, or some self-described tabular data.
>

The latter approach has generally turned out to be a mistake. Often, all it
achieves is to shift compatibility problems to a different level, where the
problems may not be recognized, or there may be no standards process to
deal with them, or the usual methods for feature detection do not work.

If you want to have Mozilla-specific extensions, be honest about it and
just add them to the WebExtensions API.

One option here might be to have an API that returns strings of
human-readable text, although that's dangerous too because people might try
to parse it.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Robert O'Callahan]

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 
> off when #1345661 has been resolved. As I said, the true solution for Firefox 
> is to use PortAudio. No need for libcubeb.

We looked at PortAudio a long time ago and it had major problems.
Apparently it still did as of 2014:
http://camlorn.net/posts/december2014/horror-of-audio-output.html

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 hneireseoouot.tniesiewaoeivatewt sstvr  esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Robert O'Callahan]

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 get a
>> chance.
>>
>
> Ryzen currently on Linux implies no rr, so beware of that.

A contributor almost got Piledriver working with rr, but that was
based on "LWP" features that apparently are not in Ryzen. If anyone
finds any detailed documentation of the hardware performance counters
in Ryzen, let us know! All I can find is PR material.

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 hneireseoouot.tniesiewaoeivatewt sstvr  esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
>instead of repeatedly iterating on review comments)
>
>  * reduced friction for existing contributors working in new areas
>of the codebase
>
> which outweighs indvidual style preferences or historic module
> differences here.

Also, it's very liberating not having to think about formatting while
writing code, knowing it will be automatically fixed up later. This is
especially helpful for partially-automated changes such as mass
find-and-replace.

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 hneireseoouot.tniesiewaoeivatewt sstvr  esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Robert O'Callahan]

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 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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
> available.  I don't know how prevalent the ones that do are in practice...
>

Also, for this to matter, it has to be the *browser* (or at least something
other than the service worker's Web application) consuming the results of
the download. If the Web application is consuming the results of the
download, it could presumably be altered to consume chunks delivered from
the service worker.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 (ServiceWorker [DOM]) Cache API[1]
> is a great place to store the result.  What's less clear is how best to
> handle allowing the user to begin watching the movie when the download is
> still in-progress.
>

It seems to me that authors could solve this using MSE for playback and
breaking the file into chunks.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Robert O'Callahan]

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 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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Robert O'Callahan]

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  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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Updated chaos mode on rr master

[Robert O'Callahan]

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 reproducible.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Robert O'Callahan]

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.
>>
>
> Well, and platform (OS) support for rr, right? And rr also doesn't
> effectively support debugging frontend JS tests, AIUI? Have either of those
> changed recently? For example, one of the most frequent intermittents in
> "my area" is: https://bugzilla.mozilla.org/show_bug.cgi?id=1130411 . But
> that's Windows only and pretty much all frontend JS code.


Good points. Just because a test only shows up on one platform in
automation doesn't mean rr can't find it on Linux. It could be a
cross-platform bug that just happens to hit the right conditions on one
platform; we've already seen a couple of examples of this.

Front-end JS code isn't easy to debug with rr but it is possible with JS
engine gdb helpers if you're desperate. Setting breakpoints in Gecko code
to catch JS touching native objects or calling JS callbacks, plus liberal
use of ::DumpJSStack, helps.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Robert O'Callahan]

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 developers) try to reproduce intermittents, and then have
> developers download the records and corresponding VM would be very
> useful. If not, we'd need a system like we have for build/test slave
> loaners.
>

Currently that isn't supported. It could be implemented, possibly with VM
and/or kernel changes. In the short term it's easier to provide ssh access
to the machine with the recording.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Robert O'Callahan]

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
> really want to get a feeling for is how often we find actual bugs in the
> product.
>

Yes. So far I've found three Gecko bugs, but we'll find many bugs in tests.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

rr chaos mode update

[Robert O'Callahan]

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
and fix recorded test failures. Anyone should be able to set up a VM on
their local machine, build Firefox, record some failures and fix them. For
best results, run just one test that's known intermittent, or possibly the
whole directory of tests if there might be inter-test dependencies. Use
--shuffle and --run-until-failure. The most convenient way to run rr with
chaos mode is probably to create a script rr-chaos that prepends the
--chaos option, and use --debugger rr-chaos.

Lots of tests have been disabled for intermittency over the years. Now we
have the ability to fix (at least some of) them without much pain, it may
be worth revisiting them, though i don't know how to prioritize that.

We might want to revisit our workflow. If we had the ability to mark tests
as disabled-for-intermittency explicitly, maybe we could automatically
disable intermittent tests as they show up and dedicate a pool of machines
to reproducing them with rr.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

[Robert O'Callahan]

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:
>>
>> > 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 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. […]
>> >>
>> >
>> > Thanks Roc, I will give it a try.
>> >
>> > On the other hand, I used to rely more on the "-c" option to achieve a
>> > similar thing in the past, instead of the "-e" option.
>> >
>> > The reason I did so being that the thread I am interested in does a few
>> > syscalls compared to the rest of the program.  Thus I felt that using
>> "-e"
>> > option would give it an unfair large time slices compared to what is
>> > supposed to happen if the threads are running concurrently.
>>
>>
>> The -e option is gone now because the new scheduler (with or without chaos
>> mode) does not take system calls into account when calculating the length
>> of a timeslice. We only count conditional branches.
>>
>
> So we context switch at a syscall now only when the current thread happens
> to become unschedulable?
>

Or if any higher-priority thread has become runnable. This includes not
just a low-priority thread doing a FUTEX_WAKE to wake a high-priority
thread, but also a thread changing its priority or another thread's
priority, or even a low-priority thread writing to a pipe that a
high-priority thread is reading from. (Though in the latter case the
scheduler *might* not see the high-priority thread become runnable in time
in all cases.)

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

[Robert O'Callahan]

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 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. […]
>>
>
> Thanks Roc, I will give it a try.
>
> On the other hand, I used to rely more on the "-c" option to achieve a
> similar thing in the past, instead of the "-e" option.
>
> The reason I did so being that the thread I am interested in does a few
> syscalls compared to the rest of the program.  Thus I felt that using "-e"
> option would give it an unfair large time slices compared to what is
> supposed to happen if the threads are running concurrently.


The -e option is gone now because the new scheduler (with or without chaos
mode) does not take system calls into account when calculating the length
of a timeslice. We only count conditional branches.

Bugs that require very frequent fine-grained context switching are probably
still hard to find with chaos mode, because very frequent context switching
slows down recording tremendously and I didn't want chaos mode to slow down
execution by more than a bounded amount. So you may find that -c is still
needed.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Using rr chaos mode to find intermittent bugs

[Robert O'Callahan]

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 this
successfully to find difficult bugs. Even though rr works only on desktop
Linux (including VMs), I've reproduced a bug that only showed up in
automation on Android, and khuey reproduced a bug that only showed up on
OSX 10.6.

I'm continuing to do experiments to try to reproduce more of our top
intermittents, but you may already find rr chaos mode useful. I recommend
running a single test or a small group of tests continuously; one of my
bugs only had a few failing runs out of a thousand. I'm sure there are
still bugs rr can't reproduce, and I'm very interested in hearing about
bugs that eventually get fixed but that rr was not able to reproduce. By
studying such bugs we can improve rr chaos mode so it can find them.

Obviously, once rr chaos mode has proved itself, we should get some
automation around it. I'd like a bit more experience with it before we have
that discussion.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

[Robert O'Callahan]

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 cases rr chaos mode might
trigger bugs that don't normally happen, that one way or another block you
from finding the bug you care about.

However, bugs found by rr chaos mode should all be "real bugs". I'd
certainly love to hear about any cases where that's not true.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

[Robert O'Callahan]

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

[Robert O'Callahan]

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 in my mind.
> I'm open to suggestions!
>

Why not make them context-sensitive? Show the Web Audio tool if the page
uses Web Audio, Shader Editor if the page uses WebGL, Canvas if the page
has a 2D canvas, Storage if the page uses IndexedDB, Memory if the page
uses memory :-). Well, for memory, use some heuristic like if the page
spends more than 16ms in a single GC.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[Robert O'Callahan]

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 passes but with different output, then either there is no
problem or the test is incomplete and should be changed.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
> > you could, say, select text on a 3d surface with a mouse or use an
> >  tag.  It seems like this would be possible if the vertex/pixel
> > shaders were constrained to, say, affine transformations which starts
> > to sound rather similar to the whitelisting approach mentioned
> > elsewhere in this thread for mitigating timing attacks.
>
> I think this should be handled outside of the WebGL API. This seems to
> be a bunch of extra work and complexity to handle a relatively narrow
> use-case. I believe it's much easier to just provide functionality in
> the platform to allow a library to implement such specific uses.
>

Some features are always going to be really hard to provide with fully
custom UI. For example , for security reasons. Also full
custom UI for text entry is practically impossible to implement on par with
browser built-in UI, due to the need to integrate with system IMEs,
assistive tech, spellchecking dictionaries, etc.

That's why I think finding ways to integrate live Web content into WebGL
scenes would be really valuable.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 and there. I don't see how content changes would have an impact
> since you can only change the policy through navigation at which point
> you'd have a new global and such anyway.
>

Some of the things that would need to be handled:
--  controls need to not expose sensitive data about
file paths
-- For SVG images we disable native themes to avoid those being inspectable
by the Web site
-- Non-origin-clean canvas images,  frames and MediaStream frames
would have to be suppressed
-- Non-same origin content (, , etc) would have to be blocked.
This isn't as simple as a change to Fetch, since a site could create an
element and load its contents in an unrestricted browsing context and move
it into a different document with different rules.
-- :visited

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 existing UI. I think this is much simpler than dredging around in
> the WebGL API.
>

That might work. It'd get complicated for touch events. Also there are
security considerations since right now a page can't generate events that
go through into cross-origin s (though in practice it can use
clickjacking to make them happen, in many cases).

There's still the output side, of course.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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.
> jgilbert has started on a mechanism we can use for now for this case as a
> chrome-only API (Bug 1237489).
>
> For the second case, which could benefit everyone, we would like to use
> DOM elements in any WebGL scene.  The intent would be to deprecate the API
> added in Bug 1237489 once the Khronos specification for
> WEBGL_dynamic_texture is more mature and can be used in unprivileged
> content.  jgilbert mentions that the WEBGL_dynamic_texture specification is
> due for a pruning refactor that should simplify things a bit.
>
> Would it help to reduce the scope and brittle-ness of the security model
> by white-listing elements that are allowed in non-privileged content?  The
> original WEBGL_dynamic_texture proposal names specifically
> HTMLVideoElement, HTMLCanvasElement and HTMLImageElement.  Perhaps these
> would be a good start, with an intent to expand later?
>

I don't think this really helps since the element types are only part of
the problem.

If we wish to style content in a way that it gets sanitized of security
> sensitive content, perhaps we could roll it up in a convenient CSS
> attribute applied to the element we are capturing as a texture while also
> ensuring that the element generates a layer and is taken out of flow from
> the 2d document.
>
> How would you feel about this CSS:
>
> position: embed
>
> It would work like "position: absolute" in that it takes the element out
> of flow; however, the element would not be positioned or rendered in the 2d
> layout.  It would also ensure that the element generates a layer, similar
> to "will-change: transform".  When called from non-privileged content, it
> would enforce the whitelist, CORS, and sanitize any security sensitive
> output such as those that Roc has identified earlier.
>

I don't think this really helps either since it still leaves us with the
core problem: a security model that's hard to spec, hard to implement, and
hard for authors to understand. Different ways to opt into it don't address
that.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 there are so many things that need to be plugged, it would
> > make the feature very fragile: change the Web content in some subtle way
> > and suddenly it looks wrong or disappears altogether for no apparent
> reason.
>
> We could also go the other way. And have some kind of opt-in flag that
> requires everything to be CORS-same-origin and doesn't allow :visited
> and plugins or some such. And if you have that enabled you get to use
> some new features. Might be easier than tracking on a per layout box
> basis whether it violates some constraints.
>

Where would you put that flag?

I think this has basically the same problems: very difficult to specify and
police, and fragile when the content changes.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 before
> capturing their textures.  For example, :visited styles should not be
> evaluated and cross-origin content should not be allowed.
>

That's an option, but it's a very large problem that's very difficult to
get right. And there are so many things that need to be plugged, it would
make the feature very fragile: change the Web content in some subtle way
and suddenly it looks wrong or disappears altogether for no apparent reason.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 resolved in a single meeting.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/
carefully I think it's designed to prevent timing attacks by forbidding
shader control flow from depending on security-sensitive texture data.

It's hard for me to judge how implementable it is, but in principle it
should be doable. It requires analysis of shader code.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 go to the list if you prefer that.

My initial thought is that it would be much simpler to leave all timing
issues up to the browser. If you draw one of these dynamic textures in a
requestAnimationFrame callback (either on the main thread or in a Worker),
the browser can guess the frame presentation time and bind the correct
source frame to the dynamic texture automatically. Latching would be
automatically scoped to the duration of the rAF callback.

My other comment is that the API currently doesn't support Workers but it
should. Perhaps the best way to do that would be an OffscreenVideo proxy
object similar to OffscreenCanvas (but without the constructor).

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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.  Creating these
> textures is something that CSS and HTML are great at.
>
> Unfortunately, I am not aware of an easy and efficient way to capture an
> animated of an interactive HTML Element and bring it into the WebGL
> context.  A "moz-element" -like API would be useful here.
>
> Perhaps we could solve this by implementing and extending the proposed
> WEBGL_dynamic_texture extension:
>
>
> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/


This proposal seems unnecessarily complex. Is there a way for me to send
feedback?

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 implement WEBGL_security_sensitive_resources to
> enforce the security model:
>
>
> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/


I wish I'd known about this proposal earlier! This looks pretty good,
though I'd always thought this would be too complicated to spec and
implement to be practical. Glad to be wrong! Although I think we should get
as much feedback as possible on this in case of hidden gotchas.

Does this sound like a good idea?  I feel that this is something that
> all WebGL developers would want, as it would make building front-ends
>
for games much easier.
>

Yes, I think together these would be very useful.

If others feel the same, I would also like to follow up with a proposal
> to make the captured HTML elements interactive through use of an
> explicit "pick buffer" added to canvases.
>

How would that work? Being able to synthesize mouse (touch?) events in HTML
elements would add another set of issues.

I assume the idea of mixing CSS 3D-transformed elements into a WebGL scene
has been rejected for some reason?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 implement WEBGL_security_sensitive_resources to
> >> enforce the security model:
> >>
> >>
> >>
> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/
> >
> >
> > I wish I'd known about this proposal earlier! This looks pretty good,
> > though I'd always thought this would be too complicated to spec and
> > implement to be practical. Glad to be wrong! Although I think we should
> get
> > as much feedback as possible on this in case of hidden gotchas.
>
> Historically in our investigations of this, it seemed very very hard
> to guarantee a lack of timing vectors, even just for arithmetic.
> (Particularly since we're handing the sources to the driver, which
> will try to optimize away as much as it can)
>

Feedback from GPU vendors would be key here, I think. I'd like to hear that
before declaring it dead. If they already did --- RIP :-).

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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 it too.
>

I think there's value in being able to plug in a device and have it just
work on the Web without any extra steps.

Yes, it gives the vendor some privilege, but given the user has chosen to
buy the vendor's device, I think that's fair. Judgement call again.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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 Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> 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.
>>
>>
>> The basic idea is similar to what we are currently doing for
>> screensharing.  Maintain a whitelist of sites that can access USB (or
>> origin+device pairs). The extension/addon just adds a set of things to
>> this whitelist.  And yes, because this is installed in the same way
>> that the worst of our addons is installed, we gain the same (limited)
>> protections that we get from the addons, including the ability to
>> block the addon if it turns out to be bad.
>>
>
> Yes, as Martin says. The usual reasoning here is "if I could get you to
> install an add-on like this, it's game over anyway"
>
>
> For the record: I think is an awful solution, but it might work here.
>>
>
> I too think it's an awful solution, just less awful than being in the
> business
> of enforcing vendor lockin for these devices.
>

What if we allow such addons but also whitelist the vendor origin reported
by the device?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 think of a
> reason why we wouldn't move as quickly as possible to requiring it.
>

I agree. I'd like to know why Nick and Patrick think this is multiple years
away. It had better not be!

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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" means a privileged browser extension whose install is
gated on user opt-in. Who creates and maintains this extension? How is it
distributed and updated? Does it work cross-browser? Once it's installed,
what is its effect?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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 ("Web drivers"?) expose "safe" API to
> > third-party applications.
> > 2) Design a permissions API that one way or another lets users authorize
> > access to USB devices by third-party applications.
> > 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
> > built into browsers.
>
> There's also
>
> 4) Design a new USB-protocol which enables USB devices to indicate
> that they are "web safe" and which lets the USB device know which
> website is talking to it. Then let the user authorize a website to use
> a given device.
>
> This is similar to what we did with TCP (through WebSocket), UDP
> (WebRTC) and HTTP (through CORS).


Yes, that's another possibility.

However, for USB the "Web driver" approach seems better than that, to me.
It makes it easy to update the vendor library to fix security bugs and
update the API. If the Web API is baked into the device firmware that's a
lot harder.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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:
>> 1) What I suggested: Whitelist vendor origins for access to their devices
>> and have vendor-hosted pages ("Web drivers"?) expose "safe" API to
>> third-party applications.
>> 2) Design a permissions API that one way or another lets users authorize
>> access to USB devices by third-party applications.
>> 3) Wrap USB devices in Web-exposed believed-to-be-safe standardized APIs
>> built into browsers.
>>
>
> I can think of at least one more:
> (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.
>

Yeah it seems like a version of #2.

I think we should definitely support #1. Trusting device vendor code with
>> access to their devices is no worse than loading their device driver, in
>> most respects. Once we support such whitelisting device vendors can expose
>> their own APIs to third party applications even with no further effort from
>> us.
>>
>
>
> Color me unconvinced. One of the major difficulties with consumer
> electronics devices
> that are nominally connectable to your computer is that the vendors do a
> bad job
> of making it possible for third party vendors to talk to them. Sometimes
> this is done
> intentionally in the name of lock-in and sometimes it's done
> unintentionally through
> laziness, but in either case it's bad. However, at least in those cases,
> the third party
> vendor can at least in principle produce some compatible downloadable
> driver
> for the device, and its not much harder to install that than to install
> the OEM driver.
>
> I don't think it's good for the Web for browser to be in the business of
> enforcing vendor
> lock-in by radically increasing the gap between the access the vendor has
> to the
> device and the access third parties do.
>

I see your point, I just don't think it's as important as you do.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Robert O'Callahan]

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
-- 
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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 this for a while, I haven't been able to come up with
> something specific that we'd risk breaking on the Web without our
> reftests/crashtests catching it...


How about a bug where we're missing a necessary FlushPendingNotifications,
and someone writes a reftest/crashtest load event handler that would
trigger the bug if not for the harness flush? That might not be worth
worrying about though.

I think we should just grind through reftest/crashtests and add an explicit
flush to every onload/load event handler. Mind numbing-work but would take
at most a week based on my count.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APZ enabled on Fennec nightly

[Robert O'Callahan]

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Why do we flush layout in nsDocumentViewer::LoadComplete?

[Robert O'Callahan]

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 page content. Also that layout flush is
non-interruptible; if we didn't do it, we might get more value from our
interruptible layout.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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.
>
> The first problem was that some tests failed as a result.  This is
> somewhat minor, really.
>
> The second problem, pointed out by the first, is that some tests stopped
> testing what they mean to be testing, because all of our reftests and
> crashtests assume layout gets flushed onload, so they can test dynamic
> behavior by doing stuff after that.
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=581685 for details.  I
> haven't had a chance to get back and really figure this out, though we
> should.


Mmmm. This could be a significant win!

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
-- 
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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
> >> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
> >> equivalents.
> >
> > I think for now we should focus on replacing usage of gfxContext with
> > DrawTarget. I think that's more important than unifying those types.
>
> Why is that more important? (Not doubting, just curious.)
>

It actually reduces run-time overhead. Also, the gfxContext API is
significantly different to the DrawTarget API so eliminating it reduces the
knowledge burden significantly.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 before gfxContext.)
>
> Er, never mind; I guess that's sort of a stupid question at this
> point, since nsRenderingContext has mostly been gutted.
>
> It still seems like, where possible, we should switch from passing
> around an nsRenderingContext or a gfxContext to passing around a
> DrawTarget.  (Presumably starting from leaf functions and moving
> up.)
>

Yes.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 thebes
> types use double-precision FP values while the Moz2D types use
> single-precision FP values.
>
> The difference in precision doesn't matter... except when it does.
> Here are four cases I've seen where a proposed change has been blocked
> by this issue:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=984278#c10
> https://bugzilla.mozilla.org/show_bug.cgi?id=1224093#c2
> https://bugzilla.mozilla.org/show_bug.cgi?id=1222325#c0
> https://bugzilla.mozilla.org/show_bug.cgi?id=1216396#c5
>
> It seems like the strategy so far has been to just make the changes,
> and then insert double-precision when it seems like it's necessary --
> the existence gfx::RectDouble is evidence of this. But it's hard to
> know when it is necessary.
>
> Another possibility would be to just change the Moz2D types to use
> double-precision, which presumably would avoid problems like the above
> ones. But I suspect that will have some opposition, perhaps for
> performance reasons and perhaps because Moz2D's use of
> single-precision mirrors some of the graphics APIs that Moz2D
> interfaces with.
>
> I'd love to find a way to break the current impasse, because
> Moz2Dification will never be completed otherwise; it has certainly
> halted my efforts on that task.
>

I think for now we should focus on replacing usage of gfxContext with
DrawTarget. I think that's more important than unifying those types.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Service Workers with FetchEvent

[Robert O'Callahan]

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 service
> workers.
>

Yes. This is incredibly important. Just look at the messaging in
http://recode.net/2015/11/09/indias-flipkart-google-launch-chrome-mobile-website-replicate-apps/

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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  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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: HTMLElement.innerText

[Robert O'Callahan]

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 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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: HTMLElement.innerText

[Robert O'Callahan]

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 Web compat. Because Mozilla, I've drafted a spec
here: https://github.com/rocallahan/innerText-spec which will hopefully
find its way through the W3C WICG, but given the state of the world, us
shipping this with or without a spec can hardly cause any more harm.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: jar: URIs from content

[Robert O'Callahan]

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 Bugzilla, but this sounds like the right thing to do.
>>
>
> If this is a common use case, then `mach test` should be able to accept a
> bz://123456 URL, autodiscover a test case attachment on that bug, download
> it, and run it.
>

Not as convenient as clicking on a link.

I guess the right fix would be to have a Web proxy service that accepts
URLs in a custom format, unpacks ZIP files and serves their contents.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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, however, highlight a shortcoming of our platform today: we can't
> achieve flawless 60fps performance without APZ. We can get close, but any
> nontrival-but-reasonable demo will encounter jank, ostensibly due to
> compositing and rendering taking too much time. (APZ pathways, rendering
> the same content, provide consistent 60fps without frame drops, leading me
> to believe that some part of the JS-driven pipeline incurs substantial
> cost.)
>
> This means that on Firefox OS, the only way to achieve buttery-smooth
> touch-driven animations is to use overflow-scrollable containers rather
> than touch events. Scrollable containers provide a reasonable abstraction
> for user-driven fluid touch animations. If we had synchronous control over
> scroll events, we could do a lot more with just this; but because of APZ,
> we can only do so much:
>
> On Firefox OS, the "utility tray" (swipe down from the top of the screen)
> is now implemented with native scrolling. However, the tray's footer, which
> is intended to only appear when the tray reaches the bottom, cannot be
> displayed without visual glitches due to APZ -- the user can scroll the
> container before JS has a chance to react.
>
> My question is this: Is APZ intended to be a stopgap measure, to compensate
> for platform deficiencies in rendering performance, or is it intended to
> become a permanent part of the web? Put another way: Is "onscroll" forever
> redefined to be "an estimate of the current scroll position", rather than a
> synchronous position callback? (I thought I overheard talk about how
> WebRender might obsolete APZ due to its performance, but I may have
> misheard.)
>
> If APZ is with us forever (and 60fps JS-based animation is out of the
> question), then I think we need to create an API that allows sites to
> provide more fine-grained control over scroll motion. I have more thoughts
> on this, if APZ is the way forward.
>
> I'd also like to better understand why a natively-scrolled container is
> able to scroll at 60fps, while the same content scrolled with rAF +
> transforms cannot. If the rendered content is the same, where is the
> bottleneck? (I can provide test-cases/demos if desired.) I'd like to help
> out with addressing this deficiency, but I don't have enough Gecko
> experience to know where to begin.
>

The reason for that would depend on the details of the testcase. For many
pages, on low-end phones, the answer would be that after each rAF callback
Gecko spends more than the frame budget just rebuilding display lists and
layers. This is something we're working on but there's a lot of work to do.

AFAIK there isn't yet a cross-browser consensus answer to your main
question. I think a possible and desirable future would be for APZ to only
kick in as a fallback measure once we have determined that the application
is unable to maintain an adequate frame rate with main-thread rendering.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 is VP9 and a peer protocol (RTP) not compatible to existing
> streaming environments (RTMP, HLS).

It requires a proxy/transcoder. It also does not allow local recording in
> mp4 properly,


FWIW Firefox for Android and FirefoxOS support recording WebRTC streams to
MP4 locally. Desktop Firefox supports recording to WebM. Do you have a
use-case for recording locally to MP4 on desktop?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

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... Someone fixes up a thing completely, adds
>> it to a whitelist, and then it's a simple pass/fail. Could that work
>> here too?
>>
>
> Yes, that is another option for checks that tons of existing code don't
> pass.


That'll help some.

The problem of attributing new errors to the correct part of the diff
remains, and is quite interesting.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

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 makes it all
> too easy for people to forget to turn on these builds from their trychooser
> syntax) so as soon as the code is pushed to try (perhaps through autoland)
> the check failures will be visible as build failures.  I'm not quite sure
> what it would take to get those build failures to appear in MozReview but
> it should be possible.
>

The tricky bit is to determine which failures were introduced by the patch,
and just display those, and display them in the context of the patch in
some way that makes sense.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

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
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Considering dropping Talos support for Linux32

[Robert O'Callahan]

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 developers
spending time on it.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Robert O'Callahan]

On Fri, Sep 25, 2015 at 5:41 AM, Sylvestre Ledru 
wrote:

> Any questions, comments?
>

This whitepaper on Infer is an interesting read:
https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xap1/t39.2365-6/10935986_985284008163608_74391_n/Moving_Fast_with_Software_Verification.pdf
(misleading title though).
(Apart from the comments about the tool, I like the observation that mobile
app development is a problem for Facebook compared to Web because they have
to support old versions of their app.)
One of the key things in that paper, which I've claimed for a while, is
that the real value of static analysis tools for developers like us is to
apply them at code review time. That's when developers are motivated to
clean up, explain, and fix their code, and when it's cheapest to do so. So
I'm looking forward to having support in Mozreview for automated drive-by
reviews, and then it would be really valuable to adapt these tools to do
such reviews --- at least as valuable as running them over the whole
codebase.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Editbugs access for Chromium bug tracking

[Robert O'Callahan]

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 we'll see about getting it for you. If you just want something specific
done in their bug tracker, I can proxy that for you.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Canvas CaptureStream

[Robert O'Callahan]

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:
https://docs.google.com/document/d/1JmWfOtUP6ZqsYJ--U8y0OtHkBt-VyjX4N-JqIjb1t78/edit#heading=h.2ki8zk71f7w2

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Robert O'Callahan]

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 rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How would you like to spell check this?

[Robert O'Callahan]

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"
> something here, someone has told us that they actually want a different
> behavior.  As such, I think that any change here must be performed as a
> larger project to fix our spell checking UI.  Even fixing bugs in this code
> has proved to cause more issues."
>
> I even have proof, that this is *not* a good argument, since one aspect of
> the general spell checking problem (bug 717433) already has an accepted
> solution.
>

I don't intend to pick a fight with Ehsan over this. I believe what he
wrote there. The patch in bug 717433 just seemed like an especially clear
improvement.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
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

[Robert O'Callahan]

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 'load' event?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
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

[Robert O'Callahan]

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 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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 google search page.

 Is this the proper place to report such bugs ?


Please file bugs in Bugzilla!
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
in the Panning and Zooming component.

Thanks!
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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implement Fetch?

[Robert O'Callahan]

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 detail, possibly; the reason we do it
 is that we had a bunch of code that assumed you could go from a request to
 its loadgroup to its docshell to its document, but for SVG paint servers
 that would produce the linking SVG document, not the paint server document,
 which would not have been right in various cases.


We've already agreed to make resource document loading go away and resolve
remote SVG resource URIs by loading those documents as images instead.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Robert O'Callahan]

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 will silently fail to
   restart after the upgrade.


How many people is that? Do we run on GTK 3.0 or is 3.4 required?

If GTK3 isn't present can we start distro Fireofx instead?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Robert O'Callahan]

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 anything on elm.

 Well, it looks like they are now all gone. :)


Great! Let's switch now, before they come back! :-)

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement HTMLMediaElement.srcObject partially

[Robert O'Callahan]

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 Blob/File.

It would be best to store a reference to the Blob or File in the
HTMLMediaElement and let the cycle collector do the work --- like we
currently do for MediaStream srcObjects.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement HTMLMediaElement.srcObject partially

[Robert O'Callahan]

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 implementing Blob/File support would be
 quite trivial. Just make

 elem.srcObject = blob;

 internally call

 URL.revokeObjectURL(this.mOldObjectURL);
 this.mOldObjectURL = URL.createObjectURL(blob);
 LoadSrc(this.mOldObjectURL);


With this implementation, if you set elem.srcObject = blob and then release
all references to the media element, the media element is GCed and the Blob
is leaked. Avoiding that is exactly why the srcObject API is preferred over
createObjectURL.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: GTK3 linux builds

[Robert O'Callahan]

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 holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement W3C Manifest for web application

[Robert O'Callahan]

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 with Alex, but not regarding the perceived need
 for app discoverability; I hear Google has a way to solve that
 problem.)


As long as platforms exist with homescreens and other inventories of
installed apps, of which the browser is one, it seems worthwhile to me to
support adding Web apps to those inventories so they're peers of native
apps instead of having to go through a level of indirection by launching a
browser, making them second-class.

We can argue that such platforms shouldn't exist, but we also have to work
with the reality that they do.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement HTMLMediaElement.srcObject partially

[Robert O'Callahan]

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 quite close to that over the last several years. Maybe renaming
tools could understand and enforce the relationship with WebIDL, but is _
identifiers everywhere except where we're matching specs the optimal
long-term state?

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 argument.


It increases the overhead of extracting part of a large function into a
helper function, because typically some local variables become parameters
of the helper function, so they have to be renamed.

Admittedly, C++ already inhibits this refactoring by (usually) requiring
helper method declarations to be repeated in the class declaration ...
which is one of the things I most dislike about C++. But every increase in
overhead reduces the likelihood that the refactoring will be done when it
should.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 have special style for class data members. I
think highlighting data members is more useful than parameters. In fact I
would love to get rid of aFoo but the last time I tried, the 'a' prefix had
considerable support.

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 hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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 ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Robert O'Callahan]

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
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revisiting modelines in source files

[Robert O'Callahan]

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
 variable naming? -- so even if we do step 2 we'll still need some
 style vigilance during reviews, and possibly some manual style fixes
 later. But that's ok, and it would still be a clear improvement over
 the current situation.


Yeah, full automation of all style rules is impossible and a non-goal.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform