Re: Doxygen output?

On Tue, Feb 21, 2017 at 12:42 AM, wrote: > My short (<2yr) experience of the code gave me the impression that only a > small amount of it has proper doxygen comments. > We must be frequenting different circles; or I'm somehow blind to them. :-) I get to look at stuff

Re: Embeddable Browser

Em terça-feira, 21 de fevereiro de 2017 21:30:19 UTC-3, Myk Melez escreveu: > > Rodolpho Porto > > 2017 February 20 at 02:38 > > Hello guys, > > > > I do not know if this serious or the right group to do this ask, but I > > will try here rss > > > > Xulrunner no

Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

Hi, Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value in some static variable or so. -Olli

Re: Embeddable Browser

Em quarta-feira, 22 de fevereiro de 2017 00:53:00 UTC-3, 段垚 escreveu: > For extended support (non-offical) of xulrunner-stub, see my project: > https://github.com/duanyao/xulrunner-stub > > For embedable gecko in Winforms, see GeckoFX: https://bitbucket.org/geckofx/ > > > 在 2017/2/20 18:38,

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

Related note: add*varcache uses a pref observer behind the scenes. Pref observers always prefix-match, and the *varcache implementation doesn't bother re-checking whether the pref for which it gets a notification matches the one you requested a cache for. So if you have prefs "blah.foo" and

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

Huh, that is a horrible bug. On 02/22/2017 01:42 PM, Gijs Kruitbosch wrote: Related note: add*varcache uses a pref observer behind the scenes. Pref observers always prefix-match, and the *varcache implementation doesn't bother re-checking whether the pref for which it gets a notification

Should cheddar-generated headers be checked in?

Looking at mp4parse, the C header is generated: https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs But also checked in: https://searchfox.org/mozilla-central/source/media/libstagefright/binding/include/mp4parse.h Is this the best current practice that

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

On Wed, Feb 22, 2017 at 01:18:33PM +0200, smaug wrote: Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

Kit helpfully pointed out that this got fixed 6 months after I filed the referenced bug, when Matt Woodrow ran into it with a different pref - https://bugzilla.mozilla.org/show_bug.cgi?id=1267868 . So ignore my caveat - pref caches should be working normally now 'even' where the cached pref

Intent to unship: "-moz-table-border-non-zero" pseudo-class outside UA stylesheet

Currently this prefixed pseudo-class is accessible everywhere, but it is actually only used in our UA stylesheet so far. In bug 1341925 [1], I'd like to restrict this pseudo-class to only be usable inside UA stylesheet. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1341925 - Xidorn

ANN: Finally changing the default bug view for BMO on March 1st, 2017

tl;dr On March 1st, 2017, the BMO Team is going to make another attempt at changing the default bug view to the new modal view that has been in development for a while. For those who would like to use the old form, instructions on how to switch back are below in the background information. The

[Firefox Desktop] Issues found: February 13th to February 17th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *February 13 - February 17* (week 7). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Embeddable Browser

Rodolpho Porto 2017 February 22 at 03:13 Hello Myk Melez, First of all, thank you for your response! I'll talk about the project, it's a kiosk-style browser, using XULRunner 24.0b10 32bit and SWT, the modifications we made were according to project needs and

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On Thu, Feb 16, 2017 at 2:57 PM, L. David Baron wrote: > On Thursday 2017-02-16 13:20 -0500, Benjamin Smedberg wrote: > > I'm surprised and disheartened that "land it and see what breaks" is > > considered an acceptable strategy for pretty much any commit, but > > especially

Re: Should cheddar-generated headers be checked in?

I agree with Ted and Jack. For the specific case of the mp4parse cheddar header, we currently check that in because it wasn't much hassle, and cheddar pulled in syntex-syntax as a dependency which added significantly to the build time. Eventually I want to use runtime binding generation, for the

Re: Should cheddar-generated headers be checked in?

On Wed, Feb 22, 2017 at 5:49 PM, Ted Mielczarek wrote: > Given that > the C API here is under your complete control, it seems like it's > possible to generate a cross-platform header I believe the header is cross-platform, yes. > Alternately you could just generate it at

Re: Should cheddar-generated headers be checked in?

On Wed, Feb 22, 2017, at 07:11 AM, Henri Sivonen wrote: > Looking at mp4parse, the C header is generated: > https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs > But also checked in: >

Re: Should cheddar-generated headers be checked in?

I think running bindgen at build time will be the best practice. That is certainly what stylo and the spidermonkey bindings are aiming for. This capability of bindgen is pretty new, so it will take a while before the Rust community adapts. jack. On Wed, Feb 22, 2017 at 8:49 AM, Ted Mielczarek