On 2013-07-15 3:14 PM, Anne van Kesteren wrote:
On Mon, Jul 1, 2013 at 1:01 PM, Boris Zbarsky wrote:
Another big one I'm aware of is the issue of how to treat '\\' in URLs.
In the specification this is resolved in favor of how
WebKit/Chromium/Trident go about it. Which is to treat it identica
On Mon, Jul 1, 2013 at 1:01 PM, Boris Zbarsky wrote:
> Another big one I'm aware of is the issue of how to treat '\\' in URLs.
In the specification this is resolved in favor of how
WebKit/Chromium/Trident go about it. Which is to treat it identically
to "/" but flag it with a warning in the conso
On 7/3/13 8:49 AM, Anne van Kesteren wrote:
On Tue, Jul 2, 2013 at 12:09 PM, Benjamin Smedberg
wrote:
Both resource: and chrome: have host names and need to support relative
URIs. Neither of them is a candidate for standardization, though. We should
just add them as special known schemes in our
On 07/01/2013 08:30 PM, Gavin Sharp wrote:
.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/
whi
On 7/1/13 8:30 PM, Gavin Sharp wrote:
.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
Mike Hommey wrote:
Note that some "custom" schemes may be relying on empty host names. In Gecko,
we have about:foo as well as resource:///foo. In both cases, foo is the path part.
about:foo is actually an nsSimpleURI, not an nsStandardURL, so it just
throws when you try to access its host.
On 01/07/13 19:01 , Boris Zbarsky wrote:
On 7/1/13 12:43 PM, Anne van Kesteren wrote:
I outlined two issues
below, but I'm sure there are more.
Another big one I'm aware of is the issue of how to treat '\\' in URLs.
-Boris
We also have issues with hashes and URI-encoding (
https://bugzill
On 7/1/13 4:51 PM, Mike Hommey 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. My plan is to change the URL
Stand
On 7/1/13 12:43 PM, Anne van Kesteren wrote:
I outlined two issues
below, but I'm sure there are more.
Another big one I'm aware of is the issue of how to treat '\\' in URLs.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https:/
On 04/07/13 17:22, Anne van Kesteren wrote:
> On Thu, Jul 4, 2013 at 5:17 PM, Kyle Huey wrote:
>> Presumably we could have a blacklist of the handful of protocols that are
>> internal to browsers and have compat issues. "It violates the standard"
>> isn't a very compelling argument when the stand
On Thu, Jul 4, 2013 at 5:17 PM, Kyle Huey wrote:
> Presumably we could have a blacklist of the handful of protocols that are
> internal to browsers and have compat issues. "It violates the standard"
> isn't a very compelling argument when the standard is in the process of
> being written and nobo
On Thu, Jul 4, 2013 at 1:45 AM, Anne van Kesteren wrote:
> On Wed, Jul 3, 2013 at 4:08 PM, Benjamin Smedberg
> wrote:
> > I don't understand why it matters. chrome: and resource: are both
> > gecko-specific extensions and we have no desire to standardize them.
> > Chromium uses a different schem
On Wed, Jul 3, 2013 at 4:08 PM, Benjamin Smedberg wrote:
> I don't understand why it matters. chrome: and resource: are both
> gecko-specific extensions and we have no desire to standardize them.
> Chromium uses a different scheme for their chrome: protocol.
Because doing so would be a violation
On Wed, Jul 3, 2013 at 8:08 AM, Benjamin Smedberg wrote:
> We do not want
>>
>> url = new URL(rel, base)
>>
>> to differ across engines for any rel or base
>>
>
> I don't understand why it matters. chrome: and resource: are both
> gecko-specific extensions and we have no desire to standardize them
On 7/3/2013 2:49 AM, Anne van Kesteren wrote:
On Tue, Jul 2, 2013 at 12:09 PM, Benjamin Smedberg
wrote:
Both resource: and chrome: have host names and need to support relative
URIs. Neither of them is a candidate for standardization, though. We should
just add them as special known schemes in o
On Tue, Jul 2, 2013 at 12:09 PM, Benjamin Smedberg
wrote:
> Both resource: and chrome: have host names and need to support relative
> URIs. Neither of them is a candidate for standardization, though. We should
> just add them as special known schemes in our parser.
Well, either we have to standar
On Tue, Jul 02, 2013 at 07:09:04AM -0400, Benjamin Smedberg wrote:
> On 7/2/2013 6:55 AM, Anne van Kesteren wrote:
> >On Tue, Jul 2, 2013 at 12:51 AM, Mike Hommey wrote:
> >>Note that some "custom" schemes may be relying on empty host names. In
> >>Gecko, we have about:foo as well as resource:///f
On 7/2/2013 6:55 AM, Anne van Kesteren wrote:
On Tue, Jul 2, 2013 at 12:51 AM, Mike Hommey wrote:
Note that some "custom" schemes may be relying on empty host names. In
Gecko, we have about:foo as well as resource:///foo. In both cases, foo
is the path part.
about URLs don't have a host name.
On Tue, Jul 2, 2013 at 12:51 AM, Mike Hommey wrote:
> Note that some "custom" schemes may be relying on empty host names. In
> Gecko, we have about:foo as well as resource:///foo. In both cases, foo
> is the path part.
about URLs don't have a host name. resource URLs might I suppose. Do
resource
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
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 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
.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 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
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
25 matches
Mail list logo
