Hi all,
I wrote some tools a while back intended to make it possible to do complex
crash stats queries locally, using downloaded crash stats data. It can do
queries using a mongodb-like query language; even based on functions (running a
function on each crash to decide whether it should
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
is relatively easy.
Yes we now have a CloneIgnoringRef. How difficult is it to make a
clone-ignoring-query? I mean for an experienced C++ developer and not a
C++ Dummies like myself.
Phil
--
Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
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.
The actual question I wanted to ask is: Are there any objections to me
or some other contributor to make overlays ignore query part
or the search were equally complicated;
nowadays ignoring the hash is relatively easy.
Yes we now have a CloneIgnoringRef. How difficult is it to make a
clone-ignoring-query? I mean for an experienced C++ developer and not a
C++ Dummies like myself.
I don't know if this would solve
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
Hi Boris.I have an issue with my addon.In Firefox F29,after debugging my add-on
i found the error message as 'ERROR: Attempt to use .WrappedJSObject in
untrusted code.Is it because of some security changes made in FF29 so that
untrusted object cannot be accessed? Could you please help me out
See my response here: http://stackoverflow.com/a/23838442/3670407
On Tue, Jun 17, 2014 at 12:23 PM, nivesh.naramse...@gmail.com wrote:
Hi Boris.I have an issue with my addon.In Firefox F29,after debugging my
add-on i found the error message as 'ERROR: Attempt to use .WrappedJSObject
in
Hi all
Dann (see below) had a query about the MimeType objects returned by
NavigatorPlugins.mimeTypes. Does anyone here have any advice about dealing with
those?
Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills
Begin
14 matches
Mail list logo
