Hi all,
We've just landed a pretty important change to how we localize our UI [0].
Starting from this week (including 66), Fluent (async and sync) will now block
layout in all three of XUL/XHTML and HTML.
That means that flashes of untranslated content (FOUC) should not be possible
anymore.
Congratulations Justin!
Excited to see this coming all together. With this change, we can now both
improve our software quality and culture of paying attention to red L10n in
treeherder :)
Thank you!
zb.
___
dev-platform mailing list
On Friday, February 2, 2018 at 2:11:02 AM UTC-8, Gijs Kruitbosch wrote:
> In the further future, I expect this type of problem will go away
> entirely because of Fluent.
That's correct! Fluent brings the concept of DOM Overlays which allow for safe
mixing between developer provided DOM
On Friday, February 2, 2018 at 1:57:34 PM UTC-8, Nicholas Nethercote wrote:
> It shouldn't be too hard, because the prefs grammar is very simple. I would
> just implement "panic mode" recovery, which scans for a synchronizing token
> like ';' or 'pref' and then continues from there. It's not
I'm looking for a good default setup for building a debug Firefox using clang
(5.0) that is at the same time usable.
With GCC I hit a good sweet spot with:
```
mk_add_options "export RUSTC_WRAPPER=sccache"
mk_add_options 'export CARGO_INCREMENTAL=1'
ac_add_options --with-ccache
I tried to build m-c today with clang 5.0 and icecream using the following
mozconfig:
```
mk_add_options MOZ_MAKE_FLAGS="-j$(icecc-jobs)"
mk_add_options 'export CCACHE_PREFIX=icecc'
mk_add_options "export RUSTC_WRAPPER=sccache"
export CC=clang
export CXX=clang++
ac_add_options --with-ccache
W dniu niedziela, 5 listopada 2017 08:18:37 UTC-8 użytkownik Gijs Kruitbosch
napisał:
> More generally, in response to Philipp's points, I'm not convinced
> pulsebot is responsible for any decrease in responsiveness. Early in the
> day here in Europe (ie when it's night in the Americas) the
This is awesome! As an engineer who has to work with C++ until we advance Rust
bindings, I always feel terrible when my reviewers spend their precious time
identifying simple C++ errors in my code.
Seeing the advancements in static analysis for C++, rustfmt and eslint for JS,
I'm wondering if
Hi dev.platform,
We're planning to switch language packs to use the new WebExtensions platform
somewhere down this week [0].
This is a very important change on that enables us to enable the first
milestone on the path to the new localization API [1].
In a longer term, we hope to promote
Hi all,
tl;dr - This will almost certainly not affect your work. We're adding a
temporary pre-commit hook that requires L10n Drivers to r+ any patches that
touch .ftl files.
As the waters calm down after 57 cycle, we're getting ready to start enabling
the new localization API in Gecko.
Hi Team,
We're currently working on removing all the code that we had for building Gecko
and SpiderMonkey without ICU.
ICU is our core internationalization library, and CLDR our core
internationalization database for both internal and external (think, ECMA402)
use.
In Firefox 56 we moved the
On Tuesday, September 5, 2017 at 8:18:40 AM UTC-7, Mike Conley wrote:
> We should also consider adding a milestone for the "hero element" for
> the browser. There's some discussion fragments in bug 1369417 about this
> (which I see you're already involved in! Great!), captured from a very
>
Gecko has a pretty substantial number of metrics used for measuring startup
performance.
We have probes in Telemetry [0], StartupTimeline [1], various uses of
MozAfterPaint, both in talos tests [2] and in production code [3][4].
We also have first paint in compositor [5], before-first-paint
One more thought. There's a project that fitzgen told me about that aims to
allow for components to communicate between JS and Rust using Streams.
If we could get to the point where instead of WebIDL/XPIDL we could just plug
streams between JS/CPP and Rust in Gecko, I believe the scope of Gecko
I'm working on a new feature which will add a new JS class.
I can grow the main file (mozIntl.js) or add it in a separate file
(mozIntlLocale.js).
For readability, I think it would be nicer if I could add it as a separate file
(I like to keep my files under 500 lines), but I don't want us to
Hi all,
The latest update in the locale rearchitecture is that we now have three
methods on LocaleService that should be used to operate on the requested
locales:
LocaleService::GetRequestedLocales
LocaleService::GetRequestedLocale
LocaleService::SetRequestedLocales
Please, use them instead
On Sunday, April 9, 2017 at 9:50:49 PM UTC-7, gsqu...@mozilla.com wrote:
> How is the browser UI locale set/chosen? If based on OS locale settings,
> great!
It's currently based on the selection of pref called "general.useragent.locale"
negotiated against resources available in ChromeRegistry.
Hi all,
We completed the transition of the Intl handling from using OS locale, to use
browser UI locale.
We have a new API called mozIntl.DateTimeFormat which should be the primary way
we format date and time in our chrome.
You can think of it as a regular ECMA402 DateTimeFormat on steroids.
Hi Firefox devs!
We just landed the final change that culminates the 3 month long major refactor
of how Gecko handles language selection [0] (pending autoland->central).
We now have a single new API - mozilla::intl::LocaleService [1] (and
mozILocaleService [2]) - which centralizes all
That's super exciting!
The new localization resources registry module is being written with async
generators in mind. I have the patch ready in the bug, which can be flipped to
go async with 8 lines of code.
I know we're not planning to make it ride trains just yet, but if you need a
On Saturday, March 25, 2017 at 8:02:36 PM UTC+1, Botond Ballo wrote:
> What you describe sounds like other types of timelines, linked to user
> gestures. There is mention of that on the wiki [1] [2], but no
> concrete proposal that I'm aware of. I would imagine contributions to
> the development
On Tuesday, March 21, 2017 at 7:46:07 PM UTC-7, Boris Zbarsky wrote:
> Are you properly handling the fact that AddStrongObserver watches all
> prefs starting with the prefix you pass it? ;)
I don't, and I'd love not to. I know perfectly well this two strings I want to
watch only them.
I don't
Is there a reason we should use RegisterCallback over AddStrongObserver?
I have a fresh API where I'm using AddStrongObserver at the moment, but would
be happy to switch if that will be cheaper / more future-compatible.
zb.
___
dev-platform mailing
On Monday, March 13, 2017 at 7:45:44 AM UTC-7, Byron Jones wrote:
> David Burns wrote:
> > We should try mitigate the security problem and fix our nit problem
> > instead of bashing that we can't handle re-reviews because of nits.
> one way tooling could help here is to allow the reviewer to make
As others stated, the idea that patch cannot be altered after r+ has a massive
effect on productivity. I can't overstate how much it would impact day-to-day
work for engineers, and I don't really see an easy way out.
Even if we added "approval to land with minor changes" there's a) no way to
Reporting first results.
We got an icecream setup in SF office and I was able to plug myself into it and
got a icecc+ccache+gcc combo with a fresh debug build in <30 min.
On top of that, I had low load on my machine, which is nice as in the meantime
I was able to work on other things.
Now,
On Wednesday, March 8, 2017 at 8:57:57 AM UTC-8, James Graham wrote:
> On 08/03/17 14:21, Ehsan Akhgari wrote:
> At risk of stating the obvious, if you aren't touching C++ code (or
> maybe jsm?), and aren't using any funky compile options, you should be
> using an artifact build for best
On Tuesday, March 7, 2017 at 3:24:33 PM UTC-8, Mike Hommey wrote:
> On what OS? I have a XPS 12 from 2013 and a XPS 13 9360, and both do
> clobber builds in 40 minutes (which is the sad surprise that laptop CPUs
> performance have not improved in 3 years), on Linux. 70 minutes is way
> too much.
So,
I'm on Dell XPS 13 (9350), and I don't think that toying with MOZ_MAKE_FLAGS
will help me here. "-j4" seems to be a bit high and a bit slowing down my work
while the compilation is going on, but bearable.
I was just wondering if really two days of patches landing in Gecko should
result in
OCLOBBER=1
ac_add_options --with-ccache=/usr/bin/ccache
ac_add_options --enable-optimize="-g -Og"
ac_add_options --enable-debug-symbols
ac_add_options --enable-debug
Here's my ccache:
▶ ccache -s
cache directory /home/zbraniecki/.ccache
primary config /hom
Deep in the dungeons of Mount nsChromeRegistryChrome[0], lies an ancient line
of code that in the Days Of Old allowed knowledgeable spellcasters to select
the locale of the user interface straight from the command line - "uiLocale"[1].
Since then, many things have changed, and folks forgot
On Tuesday, February 7, 2017 at 2:33:05 PM UTC-8, Gijs Kruitbosch wrote:
> Please can you add an alias into Services.jsm so that
> Services.locale. works ?
Yeah, filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1337551
>
> Also, that particular API looks like it might as well be a
Hi devs,
intl/locale is going through a refactor phase to get us ready for the new
localization framework and the new l10n UX [0].
As part of it, we just landed a new LocaleService that is going to take over
from nsLocaleService and nsChromeRegistry as the API for locale negotiation for
the
On Thursday, November 10, 2016 at 5:15:26 AM UTC-8, David Teller wrote:
> Ok. My usecase is the reimplementation of OS.File in Rust, which should
> be pretty straightforward and shave a few Mb of RAM and possibly a few
> seconds during some startups. The only difficulty is the actual JS
> binding.
Easily reproducible on Ubuntu 16.10, so cross platform.
Worth filling a bug?
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Monday, January 23, 2017 at 12:03:35 PM UTC-8, Eric Shepherd wrote:
> It seems to me, anyway, that the ideal solution would be to enhance HTML
> (ideally in the spec) with the features needed to build a full-fledged
> desktop UI. That would be fabulous not just for Firefox making the
Regarding choice of framework for HTML-backed UIs.
My initial suggestion is to try not to go into a fully-opinionated stack like
React.
My opinion has nothing to do with React itself, it's quality or suitability,
but with a generic approach of using an opinionated stack that diverges from
One more thing that XUL gives us is L10n.
With HTML, we can use .properties to load localization resources and inject
them into HTML, but I believe this to be a very inelegant solution with a
surprisingly high risk of bugs.
We do have an l10n framework called L20n that is supposed to replace
On Sunday, December 25, 2016 at 6:36:37 PM UTC-8, Mike Hommey wrote:
> XP_GNOME comes to a surprise to me. But then it's only used in one
> place, and defined in the same place, so it's a local thing...
Yea, it just so happens that it's browser.xul ;D
But correct, it is a local thing.
> As for
While preparing for the transition to the new localization framework, I
noticed[0] that we use a large number of loosely overlapping build-time
variables to indicate different combinations of widgets, platforms and GUIs.
It would be awesome if we could bring some consistency to that. In
So, it seems to me that we're talking about two aspects of module loading:
1) Singleton vs. per-instance
Cu.import allows us to share a single object between all the code that
references it.
ES6 modules are not meant to do that.
2) Conditional vs. static
Cu.import allows us to decide *when*
If I understand correctly es module imports work differently from JSM's
Cu.import in which scope they operate in.
JSM's are singletons, while importing in es imports code into your JS context.
How would you want to differentiate between those two modes?
Other things in the es import is that
Hi,
We're working on a rewrite of the localization infrastructure in Gecko and
tpaint is the main perf test that we're affecting.
My team has put a lot of work over last weeks to better understand tpaint tests.
The test at the moment is both noisy, and has a steady regression with each run
; >
> > What am I doing wrong?
>
> Probably your ccache cache is too small? What size did you set?
>
> - Xidorn
It fills the ccache:
cache directory /home/zbraniecki/.ccache
primary config /home/zbraniecki/.ccache/ccache.conf
seconda
On Monday, August 15, 2016 at 1:12:51 PM UTC-7, Matthew N. wrote:
> Make sure you have enabled the fsmonitor[1] extension for mercurial if
> your prompt is using `hg` commands. I believe `mach mercurial-setup` now
> helps with this.
Ugh, that helps as hell!
I installed watchman and turned on
prompt that
gives me information about branch I'm on and untracked/modified files.
This is how my shell prompt looks like on gecko-dev (git clone):
zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$
and if I modify any file it may look like this:
zbraniecki@cintra:~/projects/mozilla
One hour of reading DXR later and I *think* I want to get the timestamp of
this:
https://dxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#3809
or something around it :)
as this will tell me a couple of things:
1) Things injected into DOM after this timestamp may/will cause
On Friday, July 22, 2016 at 6:53:45 AM UTC-7, Mike Conley wrote:
> As for MozAfterPaint firing all over the place - you might find this
> useful:
> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/MozAfterPaint/mozilla.dev.platform/pCLwWdYc_GY/j9A-vWm3AgAJ
>
> See the second
On Friday, July 22, 2016 at 6:53:45 AM UTC-7, Mike Conley wrote:
> Is the firstPaint timestamp in nsIAppStartup's getStartupInfo[1] not
> sufficient? It's apparently recording the time that firstPaint occurred.
> I think you're already aware of this, but I'm in the process of
> modifying ts_paint
As part of the work we're doing to replace old l10n API (DTD for HTML/XUL and
StringBundle for JS) with new API, we're trying to measure the performance cost
of DTD, StringBundle and its replacements.
The challenge we encountered is that there doesn't seem to be a way to measure
something that
On Tuesday, June 14, 2016 at 11:51:16 AM UTC+1, Joe Walker wrote:
> I don't think you can say "It's sync unless in which case it's
> async".
> If that's that case then from the API consumers point of view, then (deep
> voodoo withstanding) it's async.
As weird as it sounds, I believe that you
On Monday, June 13, 2016 at 9:39:32 AM UTC+1, Gijs Kruitbosch wrote:
> Separately, the documentation put forth so far seems to indicate that
> the localization itself is also async, on top of the asyncness of the
> mutationobserver approach, and that could potentially result in flashes
> of
On Friday, June 10, 2016 at 10:37:04 AM UTC-7, Gijs Kruitbosch wrote:
> This async-ness will not be acceptable in all circumstances. As a
> somewhat random example: how would we localize the 'slow script' dialog,
> for which we have to pause script and then show the dialog?
Agree, there are
Hi Gijs,
On Friday, June 10, 2016 at 2:49:16 AM UTC-7, Gijs Kruitbosch wrote:
> Mutation observers or mutation events? How do you decide which elements
> you observe? Observing the entire DOM tree seems like it'd likely be
> terrible for performance once we start mutating the DOM. Have you
While working on the new localization API (See Intent to Implement post from
yesterday), we're developing bindings into UI languages used by Firefox and we
have some decisions to make that could be better answered by this group.
The general API is declarative and DOM-based. Instead of forcing
id=1279002
Current POC: https://github.com/zbraniecki/gecko-dev/tree/l20n
Link to standards:
Intl:
*) https://tc39.github.io/ecma402/
*) https://github.com/tc39/ecma402#current-proposals
- Intl.RelativeTimeFormat (
https://github.com/zbraniecki/intl-relative-time-spec )
- Intl.PluralRul
Hi David,
I'm one of the editors of ECMA 402 and a champion of multiple proposals there.
I'd like to respond to your comment:
On Saturday, April 30, 2016 at 1:26:53 PM UTC-7, David Baron wrote:
> I still find it sad that ECMAScript Intl came (as I understand it)
> very close to just
On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote:
> On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote:
> > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> > > As far as speed feeling goes, they would win to show something as soon
> > > as
On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> As far as speed feeling goes, they would win to show something as soon
> as possible and handle any post-first paint loading themselves.
That is unfortunately not consistent with my experience. People tend to
perceive
On Friday, October 9, 2015 at 6:43:02 AM UTC-7, Ehsan Akhgari wrote:
> On 2015-10-08 8:27 PM, zbranie...@mozilla.com wrote:
> > Currently, any app that needs any of that information, has to get elevated
> > privileges to let it *set* them, while almost every app that works with UI
> > will just
In a couple threads we've been debating back and forth about what we currently
have as navigator.mozHour12 in Firefox OS.
It's a tri-value setting (undefined, true, false) that we take from mozSettings
to adjust our Clock to use user chosen setting.
For a while, I've been asking to get it in
I promised a proposal:
navigator.mozSettings.get('locale.hour12').then(value => {
console.log('value for locale.hour12 is: ' + value);
});
This would be asynchronous, and only available for a small set of variables
(whitelisted).
zb.
___
We're about to start working on another API for the next Firefox OS, this time
for DOM Intl, that will operate on `data-intl-format`, `data-intl-value` and
`data-intl-options`.
It would be much easier for us to keep l10n and intl separately and
independently, but in the current model we will
63 matches
Mail list logo
