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 th
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=b&c=d
This could be written as
chrome://foo/content/bar
On 16/08/2015 19:56, Neil wrote:
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 design decisions at this point.
Then why don't you object to bug 1034999?
Because it solved a concr
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 f
On 17 August 2015 at 20:06, Philip Chee 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 or the
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 has
On 16/08/2015 13:31, Anne van Kesteren wrote:
> On Sat, Aug 15, 2015 at 9:48 PM, 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?
>
> Well, we want to get rid of XUL. I'm not sure it make
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 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 people who need to customize the browser.
I
On Sat, Aug 15, 2015 at 9:48 PM, 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?
Well, we want to get rid of XUL. I'm not sure it makes much sense to
revisit any of its design decisions at
10 matches
Mail list logo
