On 6/24/2013 11:02 PM, Justin Lebar wrote:
> Under what circumstances would you expect the code coverage build to break
> but all our other builds to remain green?
Most of the issues I saw with our old code coverage setup were directly
related to them not matching our normal production builds. We s
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place today, Monday, July 1st at 2:30 PM US/Pacific
Please add to the agenda:
https://wiki.mozilla.org/Platform/
I'd like to discuss the implications of replacing/morphing Gecko's URL
parser with/into something that conforms to
http://url.spec.whatwg.org/
The goal is to get URL parsing to the level of quality of our CSS and
HTML parsers and get convergence over time with other browsers as at
the moment it's
On 7/1/2013 12:43 PM, Anne van Kesteren wrote:
I'm interested in hearing what people think. I outlined two issues
below, but I'm sure there are more. By the way, independently of the
parser bit, we are proceeding with implementing the URL API as drafted
in the URL Standard in Gecko, which should
.sOn Mon, Jul 1, 2013 at 10:58 AM, Benjamin Smedberg
wrote:
>> Idempotent: Currently Gecko's parser and the URL Standard's parser are
>> not idempotent. E.g. http://@/mozilla.org/ becomes
>> http:///mozilla.org/ which when parsed becomes http://mozilla.org/
>> which is somewhat bad for security. M
On Mon, Jul 1, 2013 at 12:43 PM, Anne van Kesteren wrote:
> I'd like to discuss the implications of replacing/morphing Gecko's URL
> parser with/into something that conforms to
> http://url.spec.whatwg.org/
>
I know its not your motivation, but the lack of thread safety in the
various nsIURIs is
On Mon, Jul 1, 2013 at 6:58 PM, Benjamin Smedberg wrote:
> Currently protocol handlers are extensible and so parsing is spread
> throughout the tree. I expect that extensible protocol handling is a
> non-goal, and that there are just a few kinds of URI parsing that we need to
> support. Is it your
On 26/06/13 17:08, Andrew Overholt wrote:
> On 25/06/13 12:15 PM, Mounir Lamouri wrote:
>> Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We
>> should definitely not make this policy retro-apply so existing features
>> should not be affected but if someone wants to add a new
On 26/06/13 18:27, Ehsan Akhgari wrote:
2. ecosystem- and hardware-specific APIs that are not standard or of
interest to the broader web at that time (or ever) may be shipped in
a way to limit their harm of the broader web (ex. only on a device
or only in specific builds with c
Don't forget to add your prefixed API's/properties to this meta bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235
We've been very active in getting rid of prefixes as quickly as we can. I love
that CSS Flexbox shipped unprefixed after testing with an about:config flag for
several cycles.
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
On Mon, Jul 01, 2013 at 05:43:01PM +0100, Anne van Kesteren wrote:
> I'd like to discuss the implications of replacing/morphing Gecko's URL
> parser with/into something that conforms to
> http://url.spec.whatwg.org/
>
> The goal is to get URL parsing to the level of quality of our CSS and
> HTML p
12 matches
Mail list logo
