'workers' namespace removed

I'm doing an important cleanup of the worker code and I have some points to share: . 'workers' namespace is (mainly - bug 1435174) gone. SharedWorker, WorkerPrivate, WorkerRunnable, and so on, are now part of 'mozilla::dom' namespace. . no needs to do LIBS+['workers'] in moz.build if you want to

PSA: HTML injection in chrome documents is now automatically sanitized

As of bug 1432966, any HTML injected into chrome-privileged documents[1] is automatically sanitized to remove any possibility of script execution. The sanitization is whitelist-based, and only allows a limited set of HTML elements and attributes. All scripts, XUL nodes, or privileged URLs will

Re: PSA: Changes to JSM import APIs (or, Death to Cu.import)

Great to see these types of broad changes getting wins, so if there's a good way to keep up to date and ahead of these types of incoming changes, that would be great. I learned of these changes from this week's biweekly Firefox meeting the morning that they were already inbound. Activity Stream is

PSA: Changes to JSM import APIs (or, Death to Cu.import)

The Cu.import and XPCOMUtils.defineLazyModuleGetter APIs have been replaced with nearly-equivalent ChromeUtils.import() (bug 1431057) and XPCOMUtils.defineModuleGetter() (bug 1431533) APIs. Existing uses of the old APIs have been automatically rewritten, and a new ESLint rule has been added to

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 2:27 PM, Nicholas Nethercote wrote: > It might be possible that you could use about:config or the prefs API to > set a string pref that contains an invalid escape sequence that the parser > will subsequently reject. I will check that. > Thinking

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 12:50 PM, Boris Zbarsky wrote: > On 2/1/18 6:40 PM, Nicholas Nethercote wrote: > >> - prefs.js, which is written by Firefox. Firefox should always generate >> data that is accepted by the new parser >> > > OK. I assume we've double-checked that? And

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 11:32 AM, Xidorn Quan wrote: > > One approach would probably be showing a warning UI to tell people that we > fail to parse user.js and ask them to fix it. > > Not sure how complicated that approach would be. > This suggestion came up in one of the old

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 10:32 AM, Justin Dolske wrote: > > Can I presume that things which now trigger parsing issues are escaped or > errored by the relevant prefs APIs? e.g. if a caller tries to set a pref > name or value with an embedded NULL? > Only the parser has

Re: New prefs parser has landed

On 2/1/18 6:40 PM, Nicholas Nethercote wrote: - prefs.js, which is written by Firefox. Firefox should always generate data that is accepted by the new parser OK. I assume we've double-checked that? And that this was the case all along, for prefs extensions or about:config might have set in

Re: New prefs parser has landed

On Thu, Feb 1, 2018 at 4:32 PM, Xidorn Quan wrote: > What do we show when we disable legacy addons? We can probably borrow > whatever we did there. > There is no explicit notification for disabled legacy addons (you can see them in about:addons but you have to know to go look

Re: New prefs parser has landed

On Fri, Feb 2, 2018, at 10:40 AM, Nicholas Nethercote wrote: > [*] One tricky question is what to do with syntax errors. The current > behaviour is here: > https://searchfox.org/mozilla-central/source/modules/libpref/Preferences.cpp#1000-1011. > It writes the error to the browser console, but if

Re: New prefs parser has landed

On Fri, Feb 2, 2018 at 9:47 AM, Boris Zbarsky wrote: > > What happens if a user's prefs file has things that were OK but now fail? > Is it effectively dataloss in that we will not parse anything after that > and then write out the modified pref file with all the later things

Re: New prefs parser has landed

Wow. Some of that is bizarre enough that I kinda want to go look at the old parser code, but I value my sanity enough to not do so. Nice work. Can I presume that things which now trigger parsing issues are escaped or errored by the relevant prefs APIs? e.g. if a caller tries to set a pref name or

Re: New prefs parser has landed

On 2/1/18 4:04 PM, Nicholas Nethercote wrote: It is also slightly stricter; see the list at the bottom of this email for details (copied from the commit message). What happens if a user's prefs file has things that were OK but now fail? Is it effectively dataloss in that we will not parse

Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

Bug 767640 just merged to mozilla-central. This patch makes it so that Ci, Cr, Cc, and Cu are automatically defined in any chrome scope that has a Components object. Rejoice, because you no longer need to add "var Ci = Components.interfaces" into every file. I have a followup bug, bug 1432992,

New prefs parser has landed

Hi, I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1423840, which replaces the old prefs parser with a new one. The new parser is faster, safer, gives better and more accurate error messages, and is *much* easier to maintain. It is also slightly stricter; see the list at the bottom

Re: How to use Gecko in my web browser as web engine

I think probably dev-platform is a better list to get an answer regarding Gecko embedding, rather than dev-tech-layout, so posting there. I wish I could be more helpful, but I know nothing about that :). -- Emilio On 1/31/18 8:23 AM, malay emailme wrote: > Dear Sir, >I want to