Re: Moratorium on new XUL features
There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal of XUL. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... Thanks for the replies so far! I deliberately left this question vague to see what kind of responses people would give. But mostly I'm interested in code whose awfulness impacts users in a serious way. Well, most of the time the user-facing correctness problems are not serious, but nsDocLoader::mIsLoadingDocument is very bogus, causes correctness problems and has consequences that include us still having the ghost of the old HTML parser around for about:blank. (nsDocLoader in general isn't nice code.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道： There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal of XUL. There is also the command liner parser is also needed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: TV Manager API
On 2014-10-16, 11:09 PM, Sean Lin wrote: Platform coverage: Initially on Firefox OS FWIW we're trying to keep the implementation working with a dummy backend on other platforms too, in the interest of keeping the API testable on other platforms, but we are not planning to turn this API on for anything except for certified Firefox OS apps. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
The browser should cache compiled javascript code while caching html pages
Since the html pages are already cached, why not also cache the JIT compiled javascript while leaving a page? Shouldn't use too much space than the text content of the embedding page. Much less space than the image files embedded in a page. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The browser should cache compiled javascript code while caching html pages
This question returns every so often. If I recall correctly: - the JIT-compiled code is much, much, much larger than the JS source code, and just reading it from the cache may actually slow down execution of the page; - in many pages, JIT-compiled code actually depends on the interactions between the user and the page, since it optimizes the code that is actively used, so this will result in suboptimal code; - JIT-compiled code actually hardwires into the code a number of in-memory addresses, which are different between successive launches of Firefox, so this will result in code that will crash. Now, it might be possible to save some information (e.g. shapes, type information, hot code paths, etc.) Cheers, David On 16/10/14 22:45, Just Fill Bugs wrote: Since the html pages are already cached, why not also cache the JIT compiled javascript while leaving a page? Shouldn't use too much space than the text content of the embedding page. Much less space than the image files embedded in a page. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The browser should cache compiled javascript code while caching html pages
I have a short summary of why caching JIT code is not necessarily a clear win for most JS in a blog post: http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching We do machine code for asm.js, though (as also described in the post). More interesting than caching machine code is caching other bits of data that offer a lot more win per byte: - function boundaries and whether there were any SyntaErrors (so we don't have to do the initial syntax-only parse) - bytecode for the top-level script and definitely-run functions (usually this stuff is pretty cold, so bytecode is as far as it ever gets) - for the functions that do get jitted: which ones, what types were observed, etc, so we can expedite the normal warm-up and recompilation process This involves attaching blobs of stuff the JS engine wants back next time to network cache entries and a whole new path from path from Necko through Gecko to SpiderMonkey, so it's not exactly a small project :) We've actually done some initial work in this direction (motivated by b2g app performance): https://bugzilla.mozilla.org/show_bug.cgi?id=900784 but it seems to be on hold atm. I hope it resumes before long. Cheers, Luke - Original Message - Since the html pages are already cached, why not also cache the JIT compiled javascript while leaving a page? Shouldn't use too much space than the text content of the embedding page. Much less space than the image files embedded in a page. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
David, Le 14 oct. 2014 à 07:29, L. David Baron dba...@dbaron.org a écrit : Here is my current draft of the comments I plan to submit in about 12 hours (cc:ing the whole AC, I think). Sorry for not getting this out for people to have a look at sooner. Good summary of our discussions. Thanks. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
Thank you Bobby and Josh for all your work to improve ImageLib! I’m pushing hard on making it better still (with a lot of help from folks like Timothy Nikkel and Michael Wu). Hopefully next time we try to decide what the worst piece of Mozilla code is, ImageLib won’t be a candidate. =) - Seth On Oct 17, 2014, at 12:25 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Fri, Oct 17, 2014 at 1:03 AM, Josh Matthews j...@joshmatthews.net wrote: I'm not certain that the image/src/ code is as bad as you make out any more. bholley certainly is no longer the expert there; I took over a bunch of his work to clean it up a year or two ago, and Seth is the benevolent dictator now and has done some good cleanup work on it as well. Yes, I stepped down as an ImageLib peer a little under three years ago. And when comparing the initial states of ImageLib and XPConnect when I inherited them, ImageLib was a dream to work with. ;-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moratorium on new XUL features
On 16/10/2014 13:56, Robert O'Callahan wrote: On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: There are also interesting height computation issues that I'm pretty sure HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a function of the box model, considering it's not an issue with flexbox... Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width *and* height bottom up before doing actual layout. This is incompatible with CSS and really just broken, and the friction between that model and CSS is painful. Rob This is an interesting point in terms of wanting to switch to HTML here. We use quite a lot of popups and panels in the Firefox front-end code. Those size to content (and windows/dialogs have a .sizeToContent method). How would/could that work in the HTML/CSS model? (asking particularly because I'd love to have an alternative for the broken XUL layout we get now which leads to stupid bugs and wasted time and frustration - so far I've not been able to work around just by using lots of display: flex; and friends...) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: image-rendering: pixelated CSS property-value
On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
I don't see this temporary difference as particularly problematic,
particularly given that pixelated is primarily an upscaling feature,
and given that we'll match them before too long. But if others
disagree, I'm open to holding off on shipping image-rendering:
pixelated until bug 1072703 is fixed.
I would really prefer if we ship something interoperable with Chrome, so
unless bug 1072703 is a very large project, I don't think we should ship
support for pixelated without it.
Just to follow up on this:
I'm leaning towards of conservatism here following ehsan's advice to
not ship pixelated until we've got downscaling-detection implemented,
for prettier downscaling with image-rendering: pixelated. (bug 1072703)
Unfortunately, it turned out that this is a less-trivial project than I
was hoping -- it requires changes to all of our drawing paths, in all of
our per-platform gfx/2d/DrawTarget{$WHATEVER} files. It probably won't
be a ton of code, but it requires a good deal of testing/tweaking, on
every platform, to find all the paths that need adjusting, and to find
the right rects/transforms to inspect in each chunk of drawing code.
(And it likely requires some refactoring in these files, to share these
checks among the various drawing paths.)
So, I'm de-prioritizing work on pixelated for now, and I'm focusing on
finishing object-fit object-position instead. I hope to circle
back to finish of pixelated before too long, though.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Has something changed about nsITreeView (nsItreeView.setTree) lately?
Hi, I posted the following message to mozilla.dev.builds newsgroup, but I wonder if there is a mozilla-wide change to nsITreeView lately? I noticed this while testing a patch to C-C TB locally. (Considering that COMM-CENTRAL may have a slight delay in getting M-C changes, it may be that nsITreeView change may have happened a few weeks earlier or something). [Exception... Failure arg 0 [nsITreeView.setTree] nsresult: 0x80004005 (NS_ERROR_FAILURE) The error is fairly new. I did not see it on local PC until I updated the local source to build local DEBUG BUILD of TB. I thought initially it was my local patch that was causing the error, but upon investigation, it was hardly likely, and when I checked TBPL I realized it was causing trouble for everybody's compilation job. Any pointers? [I searched for nsITreeView.setTree in bugzilla but nothing came up. Is the simple search too simplistic?] TIA --- begin quote --- I think about 1/4 of 1000+ tests in |make mozmill| are failing now See https://tbpl.mozilla.org/?tree=Thunderbird-Trunk This is pretty bad, and looks to me that something about nsITreeView.setTree are the cause of major malfunctions. [Exception... Failure arg 0 [nsITreeView.setTree] nsresult: 0x80004005 (NS_ERROR_FAILURE) It is called in many places and resulted in this failure. Any idea which has caused this new regression? Simply stated, no would-be contributor can work on any patches in this state of affairs. TIA --- end quote ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Has something changed about nsITreeView (nsItreeView.setTree) lately?
On Fri, Oct 17, 2014 at 4:19 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: Hi, I posted the following message to mozilla.dev.builds newsgroup, but I wonder if there is a mozilla-wide change to nsITreeView lately? I noticed this while testing a patch to C-C TB locally. (Considering that COMM-CENTRAL may have a slight delay in getting M-C changes, it may be that nsITreeView change may have happened a few weeks earlier or something). [Exception... Failure arg 0 [nsITreeView.setTree] nsresult: 0x80004005 (NS_ERROR_FAILURE) The error is fairly new. I did not see it on local PC until I updated the local source to build local DEBUG BUILD of TB. I thought initially it was my local patch that was causing the error, but upon investigation, it was hardly likely, and when I checked TBPL I realized it was causing trouble for everybody's compilation job. Any pointers? [I searched for nsITreeView.setTree in bugzilla but nothing came up. Is the simple search too simplistic?] TIA --- begin quote --- I think about 1/4 of 1000+ tests in |make mozmill| are failing now See https://tbpl.mozilla.org/?tree=Thunderbird-Trunk This is pretty bad, and looks to me that something about nsITreeView.setTree are the cause of major malfunctions. [Exception... Failure arg 0 [nsITreeView.setTree] nsresult: 0x80004005 (NS_ERROR_FAILURE) It is called in many places and resulted in this failure. Any idea which has caused this new regression? Simply stated, no would-be contributor can work on any patches in this state of affairs. TIA --- end quote ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform This is bug 1083793/1083810. Patches accepted. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... When you get time, find someone to tell you about Morse code. (No, I don't mean Samuel.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
Ehsan Akhgari wrote: Speaking about code that causes correctness bugs that actually affect our end users, the best example that I know is editor/. Not just correctness, but the unique way it use pointers to nsCOMPtr all over... -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The worst piece of Mozilla code
Mike Hoye wrote: I mean, if you find somebody in their office today curled up in a ball, rocking back and forth and muttering mork, mork, mork over and over again, that person's having a bad flashback. Call for help, stay with them. Tell them we've got sqlite now and it's going to be OK. Those are different use cases; mork did synchronous C++ arbitrary key value store very well 15 years ago, as long as you were prepared to flush the file on the main thread. (I guess OS.writeAtomic and JSON get you there for JS these days.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Compiler version expectations
Syd Polk wrote: Does MSVC 2013 run on Windows XP? We still support Win XP for the browser; do we support building on it? You can't create a stock build on XP since the latest SDK is 7.1 and the gamepad code needs 8.0 and the DirectX code would like it too. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using __declspec(thread) on Windows
Robert O'Callahan wrote: I assume no-one's finding the Firefox libxul.dll and loading it from their own .EXE I assume people are finding the XULRunner libxul.dll and loading it from their own .EXE -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
