Re: Running source code analysis on Try

Bastien, others, On Tue, May 7, 2019 at 9:38 AM Bastien Abadie wrote: > TL;DR: We are leveraging the try infrastructure to perform source code > analysis (linters, static analyzers, etc). You can take advantage of this > to trigger other try jobs on Phabricator revisions. > What is the status

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On 16/05/2019 9:02 am, Botond Ballo wrote: Will SpecialPowers.pushPrefEnv(), which currently does propagate the prefs at least between the content and parent processes, continue to work? A lot of tests rely on this. Yes of course. The changes was to add changes so that process other than

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 07:02:58PM -0400, Botond Ballo wrote: On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard wrote: It is then up to each process to handle preference modifications and pass that change. There's no automatic or universal method on how this is done unfortunately. Will

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard wrote: > It is then up to each process to handle preference modifications and > pass that change. There's no automatic or universal method on how this > is done unfortunately. Will SpecialPowers.pushPrefEnv(), which currently does propagate the

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Hi On 16/05/2019 1:54 am, Nicholas Alexander wrote: Forgive my rank ignorance here, but as an outsider this surprises me: I expect "Gecko preferences" to be (eventually) consistent across processes.  Is this just not the case, and it's common for prefs to vary between the main and content/gfx

Re: Disabling the UINEEDED keyword

Hi Dão, Thank you for calling out that use case. This week I met with one of the UX managers to plan a replacement for the keyword. The goal here is to have a work queue that UX can triage and is visible to all the stakeholders. I'll report on that soon. -- Emma On Wed, May 15, 2019 at 3:41 AM

Re: Outline of a plan to remove all XUL documents from mozilla-central

> On May 14, 2019, at 2:43 PM, Dave Townsend wrote: > > Which test files are we talking about here? If they are testing UI widgets, > and our long-term goal is to use html and not xhtml for the UI then those > tests should, at some point, be in html. It's worth breaking the tests down into

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 6:03 AM Jean-Yves Avenard wrote: > Dear all. > > /Possibility to dynamically set a StaticPref on any threads (however, > the changes aren't propagated to other processes; doing otherwise is > certainly doable, I'm not convinced of the use case however)./ > Forgive my

Re: Outline of a plan to remove all XUL documents from mozilla-central

This was linked already - but comment #0 and the deps of that bug only mention no longer relying on the XULDocument interface. That's different from "detect and parse .xul files as XHTML" (at least, I think it is). I'd expect a separate dependency for that, but I don't see any. ~ Gijs On

Re: Outline of a plan to remove all XUL documents from mozilla-central

https://bugzilla.mozilla.org/show_bug.cgi?id=1550801 On Wed, May 15, 2019 at 6:30 AM Gijs Kruitbosch wrote: > On 14/05/2019 16:32, Brian Grinstead wrote: > >> 1. Load all XUL documents as XHTML using the prototype cache. This > >> doesn’t require any file renaming, we will just detect

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Great to see this consolidation happening; it's going to be a great improvement on the current situation. Just to check, would it be correct to assume this won't be landing on central until after the current Fx68 soft-freeze period? It seems like the sort of wide-ranging change that probably

Re: Outline of a plan to remove all XUL documents from mozilla-central

On 14/05/2019 16:32, Brian Grinstead wrote: 1. Load all XUL documents as XHTML using the prototype cache. This doesn’t require any file renaming, we will just detect a .xul file and act like it’s .xhtml. This is tracked in bug 1550801

Change to preferences via StaticPrefs, tremoval of gfxPrefs

Dear all. /TLDR; Wherever you used to use gfxPrefs, soon you will have to use StaticPrefs./ In a couple of days, once /Bug 1550422 //lands I will be retiring gfxPrefs. All features originally found in gfxPrefs are now available in

Re: Disabling the UINEEDED keyword

After reading the bug, it seems that this use case was just completely missed, and only UX people who barely use bugzilla were consulted. Therefore I'd like to ask that we re-enable this keyword until we have a proper replacement. Thanks, Dao Am Mi., 15. Mai 2019 um 12:28 Uhr schrieb Dão

Re: Disabling the UINEEDED keyword

I used the uiwanted keyword in Firefox front-end components to indicate that a bug needs UX input before it can move forward, without explicitly flagging a particular UX person because the bug has a low priority. It's valuable meta data even if nobody monitors all uiwanted bugs. How do you suggest