Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info
On Tue, Jun 16, 2015 at 3:38 AM, Chris Peterson cpeter...@mozilla.com wrote: On 6/15/15 7:22 PM, Mike Hommey wrote: On Mon, Jun 15, 2015 at 04:39:50PM -0700, Chris Peterson wrote: YouTube currently collects WEBGL_debug_renderer_info when (Chrome or IE) users submit problem reports. They have offered to share these GPU correlations with Mozilla's video team. This information would have been a huge time saver when we worked with YouTube to switch Firefox users from Flash to HTML5 video. We ran into many GPU driver bugs, from crashes to empty video frames, but we had no way to correlate these bug reports with specific GPUs or driver versions except through working with patient testers on Reddit. Isn't that the kind of correlation that should happen on our end, and not rely on individual sites doing it, though? (which, in practice, means one specific site) It's (currently!) easier for YouTube to correlate the GPU info with the particular problem (e.g. GPU decoder produces black frames) because YouTube users can right-click on the broken video and select Report playback issue context menu item. Mozilla only receives feedback from bugs reported on Reddit or Firefox's Submit Feedback menu item buried in the Help menu. Right. But note that the thing that was helpful there is not just the WEBGL_debug_renderer_info extension, but also (and way more importantly) the size of the visitor pool of YouTube. S.. perhaps we should make Firefox feedback more discoverable by adding our own Report playback issue context menu item on HTML5 video elements. It could deep-link to the existing Firefox makes me sad feedback form. If the technical information about your browser collected by the feedback form includes the GPU info, then we can do all the correlation ourselves without exposing WEBGL_debug_renderer_info to web content. That seems like a good idea. Also, we can expose actual diagnostics data to the Web content to allow them to programmatically detect and report issues. Just reporting people's driver and VGA info like this doesn't really help with that use case, unless if you have a massive user base and other issue reporting infrastructure built into your products, the way that YouTube and other large Google properties have. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info
A concrete example of this kind of thing occurred a little while ago with Google Maps. They reported that users on G41 class hardware were getting distortion when zoomed out in earth mode. This was because of our switch to D3D11 ANGLE. When we got this report we were able to reproduce the problem and block D3D11 ANGLE on that hardware. Google Maps blacklists this hardware when it can detect it using WEBGL_debug_renderer_info and if we had been exposing WEBGL_debug_renderer_info we would not have found this problem as quickly as we did. We would've been able to find this problem even faster if we had a better way for users to get this information to websites. The current process with Google Maps seems to require users to complain on their forum, for Google to ask them for the output of dxdiag and for them to manually see a pattern in the output. This is obviously a process with very low success and it seems like we could do something to make it better. -Jeff On Mon, Jun 15, 2015 at 9:18 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: I'm concerned this will discourage websites from reporting WebGL issues because it will be easier just to block whatever device has the problem they're running in to. This creates an additional burden on the web developer and essentially creates the user agent problem all over again, but at much worse scale because of the wide range of possible devices. This may be manageable for very large developers like Google but I don't think it scales across web developers. We are typically in a better position to control and update any WebGL blacklist. I've suggested that creating an easy way to rely diagnostic information to a website in the event of a problem is a better solution for improving the overall quality of our WebGL implementation and sharing that benefit with all websites instead of just benefiting large properties like Google's. -Jeff On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Summary: The WEBGL_debug_renderer_info extension allows for querying which driver (and commonly GPU) a WebGL context is running on. Specifically, it allows querying the RENDERER and VENDOR strings of the underlying OpenGL driver. By default, RENDERER and VENDOR queries in WebGL yield safe but useless values. (For example, Gecko returns Mozilla/Mozilla for RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the underlying graphics driver. These values are combined to form the WebGL Renderer field in about:support. On my system, these are: * UNMASKED_RENDERER_WEBGL: ANGLE (NVIDIA GeForce GT 750M Direct3D11 vs_5_0 ps_5_0) * UNMASKED_VENDOR_WEBGL: Google Inc. [1] Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1171228 Link To Standard: https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/ Do other browser engines implement this: Chrome and IE implement this; Safari does not. Platform Coverage: All platforms. Current Target Release: Firefox 41 Related Preferences: * webgl.disable-debug-renderer-info (default: false): Disable this extension for unprivileged content. * webgl.renderer-string-override (default: ): Overrides UNMASKED_RENDERER_WEBGL query result when non-empty. * webgl.vendor-string-override (default: ): Overrides UNMASKED_VENDOR_WEBGL query result when non-empty. Security and Privacy Concerns: * Traditional user-agent sniffing concerns. (Known antipattern) * This info includes what GPU is being used, which may contribute to marketing profiles. * This info adds easily-accessible bits of entropy that improve fingerprinting, reducing privacy. (Panopticlick and others have demonstrated that this is already very effective) Web Developer Use-Cases: * Sites can more easily and immediately identify and address concerns caused by specific hardware or drivers. Currently, apps must unconditionally workaround an issue until we can ship a fix via browser updates.This can mean performance degradation for unaffected machines for, sometimes for weeks. * Sites can collate and cross-reference drivers and hardware when tracking issues both user-reported and auto-detected, which both helps sites identify problematic hardware, and helps browsers fix these issues in turn. * This allows sites to offer better estimates of performance, and offer reasonable defaults for quality settings. [1] On Windows, we use ANGLE as an intermediary driver on top of D3D, hence the VENDOR string being Google, Inc. and not NVIDIA here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[FoxEye] Web API discussion: MediaStream with worker and ImageBitmap extension.
Hi, there, Recently, I launched FoxEye project. The goal of this project is bringing the power of computer vision and image processing to the Web. You can see more detail in [1]. To achieve the goal, we need to extend the current Web API. Right now, we just came out two drafts, *MediaStream with worker*[2] and *ImageBitmap extension*[3], and would like to discuss in public to reach more suggestions. Since we would like to standardize both specs into W3C and we believe that your suggestions would make the API better. We also open two bugs for those two API, [4] and [5]. I also discover some open questions when I implement the prototype. The followings are the questions. * - Should we need a separate VideoWorkerGlobalScope and a special VideoWorker object?- Dropping frame mechanism for WorkerMonitor and WorkerProcessor- Dispatch every video frame (flow controlled by application)- Should Gecko limited maximum on-flow VideoProcessEvent?- Should we support max FPS for the case to allow Web developer to get frame slower than original video frame rate?- The concrete definition of playbackTime in VideoProcessEven* BTW, We will have a demo in Science Fair and a session during Whistler work week. Science Fair in Whistler: 5PM~7PM, Tuesday FoxEye session in Whistler: 2PM~PM, Thursday location: may be changed to Whistler conference center due to WebRTC session conflict. Looking forward to seeing you Whistler. [1]: https://wiki.mozilla.org/Project_FoxEye [2]: http://chiahungtai.github.io/mediacapture-worker/ [3]: http://kakukogou.github.io/spec-imagebitmap-extension/ [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1108950 [5]: https://bugzilla.mozilla.org/show_bug.cgi?id=1141979 Best Regards, CTai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
On 16/06/15 17:59, Yonggang Luo wrote: I am looking forward to it. Prism? https://mozillalabs.com/en-US/prism/ -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
Graphene, the version of Gecko that runs browser.html, is basically the equivalent of electron. Still a lot to do. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1115098 https://github.com/mozilla/browser.html (see graphene issues). On Tue, Jun 16, 2015 at 5:59 PM, Yonggang Luo luoyongg...@gmail.com wrote: I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
You mean, being able to inject any script into the content?
Afaik, there's no way to do that. That's exactly why we need this API.
Do we want to keep the barrier between the browser and the content?
If so, why?
On Tue, Jun 16, 2015 at 6:08 PM, Bobby Holley bobbyhol...@gmail.com wrote:
Do privileged and certified apps currently have the ability to perform
universal XSS? Because this would give them that, certainly.
On Tue, Jun 16, 2015 at 8:57 AM, Paul Rouget p...@mozilla.com wrote:
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget p...@mozilla.com wrote: You mean, being able to inject any script into the content? Afaik, there's no way to do that. That's exactly why we need this API. Do we want to keep the barrier between the browser and the content? If so, why? Well, presumably because we might not want the browser app to be able to XSS every website ever? Maybe we're ok with that, but it's tantamount to running the browser app with system principal, which is something that we currently don't do, so presumably the b2g security people have a thing or two to say about it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Browser API: iframe.executeScript()
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
Do privileged and certified apps currently have the ability to perform
universal XSS? Because this would give them that, certainly.
On Tue, Jun 16, 2015 at 8:57 AM, Paul Rouget p...@mozilla.com wrote:
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
atom-shell is electron, what's gecko-shell would be?
I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
I was modified the chromeless to using it to building a variant version of Thunderbird, and want it to use under productive environment, cause I do a lot modificaton on chromeless so I wanna to fork it under a different name. Not so sure if that was a good idea.. 在 2015年6月17日星期三 UTC+8上午12:45:57，Paul Rouget写道： It doesn't work on windows yet. It's very much WIP. Not ready for testing. Code is here: https://hg.mozilla.org/projects/larch Where to download nightly build for Windows ? Graphene, the version of Gecko that runs browser.html, is basically the equivalent of electron. Still a lot to do. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1115098 https://github.com/mozilla/browser.html (see graphene issues). I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
Where to download nightly build for Windows ? 2015-06-17 0:10 GMT+08:00 Paul Rouget p...@mozilla.com: Graphene, the version of Gecko that runs browser.html, is basically the equivalent of electron. Still a lot to do. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1115098 https://github.com/mozilla/browser.html (see graphene issues). On Tue, Jun 16, 2015 at 5:59 PM, Yonggang Luo luoyongg...@gmail.com wrote: I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
It doesn't work on windows yet. It's very much WIP. Not ready for testing. Code is here: https://hg.mozilla.org/projects/larch On Tue, Jun 16, 2015 at 6:39 PM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: Where to download nightly build for Windows ? 2015-06-17 0:10 GMT+08:00 Paul Rouget p...@mozilla.com: Graphene, the version of Gecko that runs browser.html, is basically the equivalent of electron. Still a lot to do. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1115098 https://github.com/mozilla/browser.html (see graphene issues). On Tue, Jun 16, 2015 at 5:59 PM, Yonggang Luo luoyongg...@gmail.com wrote: I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
What would be the right approach to allow such a feature? Would adding a new permission help? On Tue, Jun 16, 2015 at 6:32 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget p...@mozilla.com wrote: You mean, being able to inject any script into the content? Afaik, there's no way to do that. That's exactly why we need this API. Do we want to keep the barrier between the browser and the content? If so, why? Well, presumably because we might not want the browser app to be able to XSS every website ever? Maybe we're ok with that, but it's tantamount to running the browser app with system principal, which is something that we currently don't do, so presumably the b2g security people have a thing or two to say about it. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 7:50 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget p...@mozilla.com wrote:
I don't how this work (Xray vision).
Given what you're doing, it's definitely worth learning about. A basic
overview is here: https://developer.mozilla.org/en-US/docs/Xray_vision
For more detail and a bigger-picture view of why this is a tricky problem,
I'd recommend watching the talk I gave in Portland:
https://air.mozilla.org/safe-by-default/ . Currently accessible for vouched
mozillians, but we should get rid of that soon.
Code, in the child process, is executed this way:
+let sandbox = new Cu.Sandbox(content, {
+ sandboxPrototype: content,
+ wantXrays: false,
+ sandboxName: browser-api-execute-script
+});
+
+let sandboxRv = Cu.evalInSandbox(script, sandbox, 1.8);
I use `wantXrays: false`, but I don't know what we really want here.
wantXrays is a deprecated option - it doesn't actually help you unless you
run with sandbox with an Expanded Principal ([content] instead of content),
which begs the whole web platform not supporting asymmetric privilege
relationships question.
This is a pretty complicated topic, and requires a fair amount of background
to discuss meaningfully, unfortunately. The links above should help a lot.
You mentioned XSS. If I understand what you're saying, introducing
`executeScript` allows anything that has access to the Browser API to
inject code to any web pages. That's exactly what it is designed for.
The Browser API already allows plenty of things. And when you have
access to the Browser API, you most certainly have access to other
critical APIs (bluetooth, file system, …). So I was under the
assumption that, at this point, we already gave a lot of permissions,
and adding a way to run arbitrary scripts is just one more of these
super power. But maybe this is a step too far.
Xrays. Is the problem that the script that is injected can be fooled?
I don't know yet if we want Xrays or not. Naively, I would say yes.
But maybe we want the script to be fool-able. That could be an
option in the executeScript method. But anyway, what is returned by
the script (a JSON object) is obviously not something that should be
trusted. It comes from the content. If wantXrays=true doesn't work
with the principal of the content, I think it's ok.
You mentioned that this is like UniversalXPConnect. I don't understand
that. It's just one more API on top of many others. Like we have
`drawWindow` accessible as with chrome privileges, we also have
`getScreenshot()` from the Browser API.
It sounds like what you're saying about is it still the web applies
to almost all the APIs we have in B2G. I don't see what's special
about executeScript that makes it less web than all the other things
we build for Gaia. Or maybe I'm misunderstanding something.
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:21 AM, smaug sm...@welho.com wrote: What is the context where the scripts would run? In the page or something more like a TabChildGlobal (the child side of a message manager) but without chrome privileges? This is also worth emphasizing - without Xray Vision (which you can't have without an elevated principal), you basically have no guarantees that your code does what you expect. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote: What would be the right approach to allow such a feature? Would adding a new permission help? Well, it sorta depends on what you're trying to accomplish. browser.html is supposed to be creating a web browser using only the web, right? If we add a privilege that more or less equates to the UniversalXPConnect of days past, is that really the web anymore? Why not just run with System Principal like Firefox does? Again, maybe we're fine with this, and maybe the B2G system app already has permissions like this (I don't know much about it - hopefully people who know more can chime in). But that's the crux of the issue we need to answer, IMO. AFAICT, the webview APIs you're comparing with are embedding APIs, and aren't ever intended to be exposed to the web. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing MozillaBuild 2.0.0 Release
W dniu 06/15/2015 o 04:18 AM, Birunthan Mohanathas pisze: VS Express 2013 for Windows Desktop seems to work fine with MozillaBuild 2. Maybe so, if you do 32 bit builds. If you want to build a 64 bit build, then MozillaBuild has removed the needed if-else clause, that was in 1.x, and assumes, that MSVC for 64 bit can be found in VC\bin\amd64 instead of VC\bin\x86_amd64 as well as it assumes, that the 64 bit vcvars file is called vcvarsamd64.bat instead of vcvarsx86_amd64.bat. It would be interesting to know, why such a simple if-else clause has been removed, which wouldn't force people to reinstall their compilers (up until now, MDN said use MSVC Express-Desktop)... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
What is the context where the scripts would run? In the page or something more
like a TabChildGlobal (the child side of a message manager)
but without chrome privileges?
On 06/16/2015 06:24 PM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget p...@mozilla.com wrote:
I don't how this work (Xray vision).
Given what you're doing, it's definitely worth learning about. A basic
overview is here: https://developer.mozilla.org/en-US/docs/Xray_vision
For more detail and a bigger-picture view of why this is a tricky problem,
I'd recommend watching the talk I gave in Portland:
https://air.mozilla.org/safe-by-default/ . Currently accessible for vouched
mozillians, but we should get rid of that soon.
Code, in the child process, is executed this way:
+let sandbox = new Cu.Sandbox(content, {
+ sandboxPrototype: content,
+ wantXrays: false,
+ sandboxName: browser-api-execute-script
+});
+
+let sandboxRv = Cu.evalInSandbox(script, sandbox, 1.8);
I use `wantXrays: false`, but I don't know what we really want here.
wantXrays is a deprecated option - it doesn't actually help you unless you
run with sandbox with an Expanded Principal ([content] instead of content),
which begs the whole web platform not supporting asymmetric privilege
relationships question.
This is a pretty complicated topic, and requires a fair amount of
background to discuss meaningfully, unfortunately. The links above should
help a lot.
bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? -Jeff On Tue, Jun 16, 2015 at 5:11 PM, Mike Hommey m...@glandium.org wrote: On Tue, Jun 16, 2015 at 04:16:13PM -0400, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. If anyone has any reasons for us not to make this change it would be good to know now. FWIW, I believe Fedora is already shipping GTK3 builds of Firefox. I depends on what our target GTK3 version would be. If, as recently suggested, we go with 3.14 as the minimum supported, that's fairly new (9 months old), and switching our builds to GTK3 would make us drop support for a lot of people that use older systems. I thought we'd be shipping both GTK2 and GTK3 builds for a while. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Tue, Jun 16, 2015 at 05:13:48PM -0400, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? The test machines *have* gtk 3.4, so at the moment, we *have* to support 3.4. It was suggested that we update the requirement to 3.14, which would require test machine upgrades or separate test machines. It may or may not happen, but the question still remains whether that's the desired end state. Supporting older gtk3 *can* be painful. It /might/ make sense to drop support for gtk3 3.14 *and* keep gtk2 builds around for a while. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote: What would be the right approach to allow such a feature? Would adding a new permission help? Well, it sorta depends on what you're trying to accomplish. browser.html is supposed to be creating a web browser using only the web, right? I really hope we're *not* trying to accomplish that. It will probably never be possible to implement a web browser using just web technologies. A web browser needs the ability to do things like clearing cookies for arbitrary domains, rendering websites that doesn't want to be iframed, and grant/deny websites the ability to use geolocation. We don't want arbitrary websites to be able to do those things. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Tue, Jun 16, 2015 at 04:16:13PM -0400, Jeff Muizelaar wrote: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. If anyone has any reasons for us not to make this change it would be good to know now. FWIW, I believe Fedora is already shipping GTK3 builds of Firefox. I depends on what our target GTK3 version would be. If, as recently suggested, we go with 3.14 as the minimum supported, that's fairly new (9 months old), and switching our builds to GTK3 would make us drop support for a lot of people that use older systems. I thought we'd be shipping both GTK2 and GTK3 builds for a while. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley bobbyhol...@gmail.com wrote: Do privileged and certified apps currently have the ability to perform universal XSS? Because this would give them that, certainly. The Browser API runs content in a separate cookie jar. That means that the browser API from a security point of view is no more capable than systemXHR. I.e. it's even less capable than cross-site XHR since it doesn't use the user's normal cookies. I.e. the Browser API is just a systemXHR API plus a really good implementation of a web rendering engine in JS. That effectively means that this is not universal XSS. The browser API can only be used to XSS things that it itself has rendered. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. Also Gtk3 API story and deprecations is quite (I don't have a polite word that is appropriate) interesting: They deprecated API created in early 3.x to replace with API from later. So you get deprecation notice (there for possibly more bugs) despite the claim of API stability. And the theme support broke on a very regular basis. This would (IMHO) help the developers as well. That's just my 2¢. Hub ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: atom-shell is electron, what's gecko-shell would be?
It's too early for that. For Graphene at least. On Tue, Jun 16, 2015 at 6:50 PM, Yonggang Luo luoyongg...@gmail.com wrote: I was modified the chromeless to using it to building a variant version of Thunderbird, and want it to use under productive environment, cause I do a lot modificaton on chromeless so I wanna to fork it under a different name. Not so sure if that was a good idea.. 在 2015年6月17日星期三 UTC+8上午12:45:57，Paul Rouget写道： It doesn't work on windows yet. It's very much WIP. Not ready for testing. Code is here: https://hg.mozilla.org/projects/larch Where to download nightly build for Windows ? Graphene, the version of Gecko that runs browser.html, is basically the equivalent of electron. Still a lot to do. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1115098 https://github.com/mozilla/browser.html (see graphene issues). I am looking forward to it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Wed, Jun 17, 2015 at 9:57 AM, Hubert Figuière h...@mozilla.com wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. Seems like we could work around that bug. 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: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget p...@mozilla.com wrote: The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)? In that case it seems reasonable to swap out the System Principal for a privilege called UniversalXSS - just make sure it's clear that that's what it does. ;-) I will add a special permission called universalxss. I'll ask you, Paul and Jonas to look at the patch. Also, the eval API should almost certainly be asynchronous, right? Current patch is asynchronous. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Performance Working Group
On 6/12/15 3:08 PM, L. David Baron wrote: http://www.w3.org/2015/05/webperf-charter.html So I have two main comments on the way this working group is operating. Not sure how these can/should be reflected in the charter. 1) The deliverables and their interrelationships are a bit of a mess. See the thread I started at https://lists.w3.org/Archives/Public/public-web-perf/2015Jun/0057.html. I would like the working group to explicitly pursue addressing those issues. 2) The way the working group operates in discussion terms seems to largely be through telecons. github issues are used some, but you have to know about them to pay attention to them, and they don't seem to be a common discussion venue anyway. The mailing list seems to be a bit of an afterthought, and it's not uncommon for mails to the list to be completely ignored by the editors of the relevant specifications. They've gotten a bit better on this front, but this is one of my main problems with this working group. Past that, I think there should be something explicit in the deliverables about extending the various APIs involved to workers and about making it possible to map timestamps between timelines in different globals. This is already being worked on actively, so should not be controversial, but should be a bit more specific than just incremental revisions to a bunch of specs. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:24 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 11:45 AM, Paul Rouget p...@mozilla.com wrote: You mentioned XSS. If I understand what you're saying, introducing `executeScript` allows anything that has access to the Browser API to inject code to any web pages. That's exactly what it is designed for. The Browser API already allows plenty of things. And when you have access to the Browser API, you most certainly have access to other critical APIs (bluetooth, file system, …). So I was under the assumption that, at this point, we already gave a lot of permissions, and adding a way to run arbitrary scripts is just one more of these super power. But maybe this is a step too far. This is the root of the question yes, which I can't answer - it needs answering from people like Jonas and Paul T on the b2g side, as well as yourself from the browser.html side - is the goal just to switch Firefox from XUL to HTML, or to be able to run your browser in your browser? The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. I asked Paul to sec-review the current patch. Xrays. Is the problem that the script that is injected can be fooled? I don't know yet if we want Xrays or not. Naively, I would say yes. But maybe we want the script to be fool-able. That could be an option in the executeScript method. But anyway, what is returned by the script (a JSON object) is obviously not something that should be trusted. It comes from the content. If wantXrays=true doesn't work with the principal of the content, I think it's ok. Xrays aren't in a spec and probably never will be. They're required if you want to interact synchronously with untrusted code, but not strictly necessary if you only want to use message passing (which is the right design choice, I think). If you treat all responses as untrusted, it's just a question of making your in-content code robust against all the millions of ways that content can pollute the global environment - i.e. a functionality problem rather than a security problem. You mentioned that this is like UniversalXPConnect. I don't understand that. It's just one more API on top of many others. AFAIK, we don't have another API that allows arbitrary XSS from non-System-Principaled code. That's exactly what UniversalXPConnect does (turns off origin checks), and effectively what your proposal does. Like we have `drawWindow` accessible as with chrome privileges Right, because the caller has system principal. we also have `getScreenshot()` from the Browser API. If that works the way it sounds, it does seem like a step in that direction. It sounds like what you're saying about is it still the web applies to almost all the APIs we have in B2G. I don't see what's special about executeScript that makes it less web than all the other things we build for Gaia. This API is fundamentally more powerful - it explicitly lets the page impersonate the user for any website in the world. That's pretty much the same catch-call as UniversalXPConnect / System Principal, and something that we may (or may not) want to avoid. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
I may be wrong, but isn't it possible to implement the same thing by injecting a `postMessage()`-based piece of code in the source code of the page during load? I'm doing just that in my HTML5 ebook reader. It's pretty annoying, because this is pre-ServiceWorker code, but I suspect that this can be done more easily with a ServiceWorker. Cheers, David On 16/06/15 17:24, Paul Rouget wrote: In bug 1174733, I'm proposing a patch to implement the equivalent of Google's webview.executeScript: https://developer.chrome.com/apps/tags/webview#method-executeScript This will be useful to any consumer of the Browser API to access and manipulate the content. For some context: the browser.html project needs access to the DOM to build some sort of tab previews (not a screenshot, something based on colors, headers and images from the page), and we don't feel like adding more and more methods to the Browser API to collect all the information we need. It's just easier to be able to inject a script and tune the preview algorithm in the system app instead of changing the API all the time we need a new thing. It also doesn't sound like a terrible thing to do as other vendors do a similar thing (Android's executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's InvokeScript). -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget p...@mozilla.com wrote: The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)? In that case it seems reasonable to swap out the System Principal for a privilege called UniversalXSS - just make sure it's clear that that's what it does. ;-) Also, the eval API should almost certainly be asynchronous, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 11:45 AM, Paul Rouget p...@mozilla.com wrote: You mentioned XSS. If I understand what you're saying, introducing `executeScript` allows anything that has access to the Browser API to inject code to any web pages. That's exactly what it is designed for. The Browser API already allows plenty of things. And when you have access to the Browser API, you most certainly have access to other critical APIs (bluetooth, file system, …). So I was under the assumption that, at this point, we already gave a lot of permissions, and adding a way to run arbitrary scripts is just one more of these super power. But maybe this is a step too far. This is the root of the question yes, which I can't answer - it needs answering from people like Jonas and Paul T on the b2g side, as well as yourself from the browser.html side - is the goal just to switch Firefox from XUL to HTML, or to be able to run your browser in your browser? Xrays. Is the problem that the script that is injected can be fooled? I don't know yet if we want Xrays or not. Naively, I would say yes. But maybe we want the script to be fool-able. That could be an option in the executeScript method. But anyway, what is returned by the script (a JSON object) is obviously not something that should be trusted. It comes from the content. If wantXrays=true doesn't work with the principal of the content, I think it's ok. Xrays aren't in a spec and probably never will be. They're required if you want to interact synchronously with untrusted code, but not strictly necessary if you only want to use message passing (which is the right design choice, I think). If you treat all responses as untrusted, it's just a question of making your in-content code robust against all the millions of ways that content can pollute the global environment - i.e. a functionality problem rather than a security problem. You mentioned that this is like UniversalXPConnect. I don't understand that. It's just one more API on top of many others. AFAIK, we don't have another API that allows arbitrary XSS from non-System-Principaled code. That's exactly what UniversalXPConnect does (turns off origin checks), and effectively what your proposal does. Like we have `drawWindow` accessible as with chrome privileges Right, because the caller has system principal. we also have `getScreenshot()` from the Browser API. If that works the way it sounds, it does seem like a step in that direction. It sounds like what you're saying about is it still the web applies to almost all the APIs we have in B2G. I don't see what's special about executeScript that makes it less web than all the other things we build for Gaia. This API is fundamentally more powerful - it explicitly lets the page impersonate the user for any website in the world. That's pretty much the same catch-call as UniversalXPConnect / System Principal, and something that we may (or may not) want to avoid. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:13 PM, Andrew Sutherland asutherl...@asutherland.org wrote: On Tue, Jun 16, 2015, at 02:45 PM, Paul Rouget wrote: You mentioned XSS. If I understand what you're saying, introducing `executeScript` allows anything that has access to the Browser API to inject code to any web pages. That's exactly what it is designed for. The Browser API already allows plenty of things. And when you have access to the Browser API, you most certainly have access to other critical APIs (bluetooth, file system, …). The other critical APIs are explicitly requested separately. It seems like it's worth making this one a separate privilege too. Or we run into the Android problem of I need this permission for this reasonable thing, but it also grants me access to do all these sketchy things, so what are you gonna do? Currently the browser API may be used for OAuth2 dance purposes for a variety of reasons. As we overhaul how we do webapps and per-app cookie jars and all that, the need for this may be removed, but right now the email app and the calendar app and probably others have the mozbrowser privilege. They do need this, but they absolutely do not need or want the ability to inject code into a google.com origin or other origins. Absolutely. I was suggesting that earlier, adding another permission. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
Why not start from 3.8?For example, I am currently using the latest stable version of Slackwarewhich supports until this GTK version.It seems there will be no new release yet. It would be nice that you take us into account! Best regards. El 16/06/15 a las 15:16, Jeff Muizelaar escribió: We're working on making all of the tests green for GTK3. This means that we could be changing the default linux configuration to GTK3 as early as FF42. If anyone has any reasons for us not to make this change it would be good to know now. FWIW, I believe Fedora is already shipping GTK3 builds of Firefox. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Tue, Jun 16, 2015 at 05:57:49PM -0400, Hubert Figuière wrote: On 16/06/15 05:13 PM, Jeff Muizelaar wrote: Is there any reason not to support all the way back to the version of GTK (3.4) on the test machines? Between 3.10 and 3.14 there are bugs in the drag and drop code in Gtk3 that make Firefox (for Gtk3) unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=983843 See upstream https://bugzilla.gnome.org/show_bug.cgi?id=728183 This was why I actually suggested bumping to 3.14. You also didn't answer whether the builds done with gtk 3.4 on the elm branch exhibit the problem when running with gtk 3.14. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
An update on progress. I've landed bugs which should clean up ~180,000 warnings. I have bugs pending for another ~26,000. The latest top 40: *Note: I improved my normalization a bit so it might look a bit different 18012 [N] WARNING: Subdocument container has no frame: file layout/base/nsDocumentViewer.cpp, line 2520 14816 [N] WARNING: NS_ENSURE_SUCCESS(EnsureScriptEnvironment(), nullptr) failed with result 0x: file docshell/base/nsDocShell.cpp, line 4605 9809 [N] WARNING: No docshells for remote frames!: file dom/base/nsFrameLoader.cpp, line 459 8929 [N] WARNING: Someone passed native anonymous content directly into frame construction. Stop doing that!: file layout/base/nsCSSFrameConstructor.cpp, line 6559 8062 [N] WARNING: Suboptimal indexes for the SQL statement 0x (http://mzl.la/1FuID0j).: file storage/mozStoragePrivateHelpers.cpp, line 109 7760 [N] WARNING: NS_ENSURE_TRUE(mDocShell) failed: file embedding/browser/nsWebBrowser.cpp, line 363 7454 [N] WARNING: anonymous nodes should not be in child lists (bug 439258): file layout/base/RestyleManager.cpp, line 1439 6294 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x: file netwerk/base/nsFileStreams.cpp, line 492 6294 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x: file netwerk/base/nsFileStreams.cpp, line 205 6131 [N] WARNING: No outer window available!: file dom/base/nsGlobalWindow.cpp, line 3920 5207 [N] WARNING: NS_ENSURE_TRUE(domWindow) failed: file embedding/browser/nsDocShellTreeOwner.cpp, line 83 5193 [N] WARNING: NS_ENSURE_TRUE(aInBrowser) failed: file embedding/browser/nsDocShellTreeOwner.cpp, line 79 5073 [N] WARNING: zero axis length: file dom/svg/nsSVGLength2.cpp, line 124 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file dom/ipc/TabParent.cpp, line 974 4574 [N] WARNING: Shouldn't call SchedulePaint in a detached pres context: file layout/generic/nsFrame.cpp, line 5181 3891 [N] WARNING: Please do not use mouseenter/leave events in chrome. They are slower than mouseover/out!: '!nsContentUtils::IsChromeDoc(d)', file dom/events/EventListenerManager.cpp, line 367 3746 [N] WARNING: Graph thread slowdown?: 'std::abs(framePosition - CurrentDriver()-StateComputedTime()) MillisecondsToMediaTime(5)', file dom/media/MediaStreamGraph.cpp, line 1193 3182 [N] WARNING: Enabling vsync compositor: file gfx/layers/ipc/CompositorParent.cpp, line 674 3042 [N] WARNING: NS_ENSURE_TRUE(mCallback) failed: file dom/base/nsFrameMessageManager.cpp, line 805 2859 [N] WARNING: '!mContentCache.CacheEditorRect(this, aIMENotification)', file widget/PuppetWidget.cpp, line 819 2859 [N] WARNING: '!editorRectEvent.mSucceeded', file widget/ContentCache.cpp, line 499 2690 [N] WARNING: nsWindow::GetNativeData not implemented for this type: file widget/PuppetWidget.cpp, line 1058 2527 [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x: file dom/base/nsContentUtils.cpp, line 3712 2526 [N] WARNING: NS_ENSURE_TRUE(domDoc target) failed: file dom/base/nsContentUtils.cpp, line 3657 2478 [N] WARNING: Subdocument container has non-subdocument frame: file layout/base/nsDocumentViewer.cpp, line 2517 2064 [N] WARNING: NS_ENSURE_TRUE(newRoot) failed: file dom/base/nsRange.cpp, line 1132 2038 [N] WARNING: NS_ENSURE_TRUE(newRoot) failed: file dom/base/nsRange.cpp, line 1231 1912 [N] WARNING: NS_ENSURE_TRUE(rootContent) failed: file editor/composer/nsEditorSpellCheck.cpp, line 715 1627 [N] WARNING: Called close() before start()!: 'mStarted', file dom/workers/MessagePort.cpp, line 215 1612 [N] WARNING: NS_ENSURE_TRUE(sf) failed: file docshell/base/nsDocShell.cpp, line 6485 1488 [N] WARNING: NS_ENSURE_TRUE(isFileURI) failed: file dom/base/ThirdPartyUtil.cpp, line 368 1417 [N] WARNING: NS_ENSURE_SUCCESS(rv, false) failed with result 0x: file netwerk/protocol/http/HttpBaseChannel.cpp, line 2077 1417 [N] WARNING: NS_ENSURE_SUCCESS(result, result) failed with result 0x: file docshell/base/nsDocShell.cpp, line 14076 1393 [N] WARNING: Break suggested inside cluster!: file gfx/thebes/gfxTextRun.cpp, line 220 1288 [N] WARNING: NS_ENSURE_TRUE(mDisabledJSAndPlugins) failed: file editor/composer/nsEditingSession.cpp, line 209 1175 [N] WARNING: NS_ENSURE_TRUE(txToRemove) failed: file docshell/shistory/nsSHistory.cpp, line 1318 1151 [N] WARNING: NS_ENSURE_TRUE(selCon) failed: file editor/libeditor/nsEditor.cpp, line 631 1149 [N] WARNING: RemoveObserver() called for unregistered observer: file hal/Hal.cpp, line 205 1142 [N] WARNING: Failed to unlock the wakelock.: '!rv.Failed()', file dom/html/HTMLMediaElement.cpp, line 2341 1113 [N] WARNING: NS_ENSURE_TRUE(aURI) failed: file netwerk/dns/nsEffectiveTLDService.cpp, line 158 I have patches pending for #1 (bug 1175289) and #5 (bug 1175249) which
Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info
On 6/15/15 7:22 PM, Mike Hommey wrote: On Mon, Jun 15, 2015 at 04:39:50PM -0700, Chris Peterson wrote: YouTube currently collects WEBGL_debug_renderer_info when (Chrome or IE) users submit problem reports. They have offered to share these GPU correlations with Mozilla's video team. This information would have been a huge time saver when we worked with YouTube to switch Firefox users from Flash to HTML5 video. We ran into many GPU driver bugs, from crashes to empty video frames, but we had no way to correlate these bug reports with specific GPUs or driver versions except through working with patient testers on Reddit. Isn't that the kind of correlation that should happen on our end, and not rely on individual sites doing it, though? (which, in practice, means one specific site) It's (currently!) easier for YouTube to correlate the GPU info with the particular problem (e.g. GPU decoder produces black frames) because YouTube users can right-click on the broken video and select Report playback issue context menu item. Mozilla only receives feedback from bugs reported on Reddit or Firefox's Submit Feedback menu item buried in the Help menu. S.. perhaps we should make Firefox feedback more discoverable by adding our own Report playback issue context menu item on HTML5 video elements. It could deep-link to the existing Firefox makes me sad feedback form. If the technical information about your browser collected by the feedback form includes the GPU info, then we can do all the correlation ourselves without exposing WEBGL_debug_renderer_info to web content. HTML5/MSE video decoding was on the pre-release channels for a few release cycles, but we didn't hit these GPU issues until MSE was on the release channel. So we need better way to collect feedback from release users. The Runtime Hardware Testing project that Jet just announced on dev-platform will help. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
