On 8/17/15 2:06 PM, Philip Chee wrote:
Yes we now have a CloneIgnoringRef. How difficult is it to make a
clone-ignoring-query?
More difficult than one would assume, because any time nsIURI is changed
we have to jump through hoops to keep the serialization/deserialization
code in principals
On 16/08/2015 13:31, Anne van Kesteren wrote:
On Sat, Aug 15, 2015 at 9:48 PM, Philip Chee philip.c...@gmail.com wrote:
The first question that occurs to me is what is the rationale? Can we
revisit this in 2015 to see if the original reason still holds?
Well, we want to get rid of XUL. I'm
On 17/08/2015 02:56, Neil wrote:
Philip Chee wrote:
The first question that occurs to me is what is the rationale? Can
we revisit this in 2015 to see if the original reason still holds?
Back then ignoring the hash or the search were equally complicated;
nowadays ignoring the hash is
On 17/08/2015 00:53, Adam Moore wrote:
Seems like this has more to do with the overlay system than XUL
itself. Losing the ability to add overlays to customize the browser
chrome would be brutal, and a move away from XUL shouldn't be done at
the expense of what the ecosystem provides today for
On 17 August 2015 at 20:06, Philip Chee philip.c...@gmail.com wrote:
On 17/08/2015 02:56, Neil wrote:
Philip Chee wrote:
The first question that occurs to me is what is the rationale? Can
we revisit this in 2015 to see if the original reason still holds?
Back then ignoring the hash
As others have said, XUL is going away.
It is not going away tomorrow.
We should be careful about if and how we invest here, so usecases are
important.
On 15/08/2015 20:48, Philip Chee wrote:
Use case 1:
chrome://foo/content/bar.xul?a=bc=d
This could be written as
Seems like this has more to do with the overlay system than XUL itself.
Losing the ability to add overlays to customize the browser chrome would be
brutal, and a move away from XUL shouldn't be done at the expense of what
the ecosystem provides today for people who need to customize the browser.
Philip Chee wrote:
The first question that occurs to me is what is the rationale? Can we revisit
this in 2015 to see if the original reason still holds?
Back then ignoring the hash or the search were equally complicated;
nowadays ignoring the hash is relatively easy.
Anne van Kesteren
On Sat, Aug 15, 2015 at 9:48 PM, Philip Chee philip.c...@gmail.com wrote:
The first question that occurs to me is what is the rationale? Can we
revisit this in 2015 to see if the original reason still holds?
Well, we want to get rid of XUL. I'm not sure it makes much sense to
revisit any of its
Bug 1034999 made XUL overlays ignore the hash portion of urls. Comment
12 has this note:
See related bug 305393 where different search strings must be treated
separately. But I think different hashes is probably ok to unify.
Bug 305393 asks that overlays ignore query strings. But this was
10 matches
Mail list logo
