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
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
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
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
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 (and testing) some more: I
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 that this was the case
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 bugs on this topic.
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 changed. The other APIs are
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 t
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 there)
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 th
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 missing?
>
There are
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
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 any
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, tha
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 o
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 build
17 matches
Mail list logo
