On 06/17/2015 01:01 AM, Mike Hommey wrote:
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
On 06/17/2015 01:01 AM, Mike Hommey wrote:
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
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/nsD
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
>
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
Yes, perpetual workarounds are an issue, but we can't handle this sort of
debugging at scale. Further, this would have been even faster (particularly
for less-common hardware) if the reporter could tell us exactly which
hardware an issue is present on. Historically, it has been difficult to
reprodu
On Wed, Jun 17, 2015 at 9:57 AM, 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 mak
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_bu
On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley wrote:
> On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget 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
> sup
On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley 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
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
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 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
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 t
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 Fi
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 mes
On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley wrote:
> On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget 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. Componen
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 b
On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget 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
Pr
On Tue, Jun 16, 2015 at 9:24 PM, Bobby Holley wrote:
> On Tue, Jun 16, 2015 at 11:45 AM, 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 exa
On Tue, Jun 16, 2015 at 9:13 PM, Andrew Sutherland
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 e
On Tue, Jun 16, 2015 at 11:45 AM, 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 allow
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
On Tue, Jun 16, 2015 at 7:50 PM, Bobby Holley wrote:
> On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget 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_vis
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, tha
On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget 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
I don't how this work (Xray vision).
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,
On Tue, Jun 16, 2015 at 10:21 AM, smaug 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 ha
On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget 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?
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 we
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 wrote:
> On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget wrote:
>>
>> You mean, being able to inject any script into the content?
>> Afaik, there's no way to d
It's too early for that. For Graphene at least.
On Tue, Jun 16, 2015 at 6:50 PM, Yonggang Luo 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 wan
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，
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)
wrote:
> Where to download nightly build for Windows ?
> 2015-06-17 0:10 GMT+08:00 Paul Rouget :
>> Graphene, the versi
Where to download nightly build for Windows ?
2015-06-17 0:10 GMT+08:00 Paul Rouget :
> 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/bro
On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget 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 becaus
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 wrote:
> Do privileged and certified app
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 wrote:
> I am
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 wrote:
> To anything that has access to the browser API. So I guess that
> includes privileged and certified apps.
>
>
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
I am looking forward to it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 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,
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 us
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
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 a
On Tue, Jun 16, 2015 at 3:38 AM, Chris Peterson
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 offere
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 wo
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 in
47 matches
Mail list logo
