Re: Intent to unship: XUL grid implementation

This is wonderful - it helps the layout engine focus on web standard implementations and gets rid of some quirky behavior in chrome UI. Thanks for your persistence Tim. Brian On Mon, Nov 16, 2020 at 5:18 PM Tim Nguyen wrote: > Hi folks, > > Thanks to Mats Palmgren & Rares Doghi, XUL grid got re

Re: A new testing policy for code landing in mozilla-central

? i.e. how often are we adding tests vs not. > > -Jeff > > On Tue, Sep 15, 2020 at 11:03 AM Brian Grinstead > wrote: >> >> (This is a crosspost from firefox-dev) >> >> Hi all, >> >> We’re rolling out a change to the review pro

Re: A new testing policy for code landing in mozilla-central

ision as a separate step _after_ adding the Project Tag. I've pinged Zeid to ask if there's any existing functionality along these lines. > Cheers, > kats > > On Tue, Sep 15, 2020 at 11:03 AM Brian Grinstead > wrote: >> >> (This is a crosspost from firefox-dev)

Re: A new testing policy for code landing in mozilla-central

#x27;t need tests. The worse thing is perhaps you cannot > effectively measure these side affects of the change. The exceptions are meant to at least partially address these points (see also ekr's point (2) above). Brian > Thanks, > Alexander. > > On Tuesday, September 15

Re: A new testing policy for code landing in mozilla-central

to discuss any specific pain points you run into with the policy. > - Andrew > > On Tue, Sep 15, 2020 at 12:28 PM Andrew McCreight > wrote: > >> On Tue, Sep 15, 2020 at 8:03 AM Brian Grinstead >> wrote: >> >>> (This is a crosspost from firefox-dev) >>

Re: A new testing policy for code landing in mozilla-central

> On Sep 15, 2020, at 8:48 AM, Jonathan Kew wrote: > > On 15/09/2020 16:03, Brian Grinstead wrote: > > > We’re rolling out a change to the review process to put more focus on > > automated testing. [...] > > As others have said, it's great that we're s

A new testing policy for code landing in mozilla-central

(This is a crosspost from firefox-dev) Hi all, We’re rolling out a change to the review process to put more focus on automated testing. This will affect you if you review code that lands in mozilla-central. ## TLDR Reviewers will now need to add a testing Project Tag in Phabricator when Accep

Re: Intent to Prototype: Constructable Stylesheet Objects

I’m happy to hear this - we have an interest in using this feature in the browser chrome. We usually load chrome://global/skin/global.css as a link in the Shadow DOM for our chrome Custom Elements and rely on sync stylesheet loading from the (chrome-only) prototype cache, but would like to stop

Can we change how [hidden] and [collapsed] work on XUL elements to more closely match HTML boolean attributes?

In order to support moving more of our frontend to HTML, I'd like to propose that we change the way `hidden` and `collapsed` attributes and properties work on XUL elements and rewrite frontend consumers to adapt. Currently, hidden and collapsed in XUL behave like: * Only a value of true hides or

Re: Can we remove xul:page?

This has now landed. I've also filed https://bugzilla.mozilla.org/show_bug.cgi?id=1584283 to do something similar with xul:wizard. Brian On Mon, Sep 23, 2019 at 3:04 PM Brian Grinstead wrote: > I've put up a patch showing what would change at > https://bugzilla.mozilla.org

Re: Can we remove xul:page?

I've put up a patch showing what would change at https://bugzilla.mozilla.org/show_bug.cgi?id=1583377 / https://phabricator.services.mozilla.com/D46869. On Mon, Sep 23, 2019 at 2:53 PM Brian Grinstead wrote: > We have 5 non-test consumers of in m-c right now:  > https://searchfox.

Can we remove xul:page?

We have 5 non-test consumers of in m-c right now: https://searchfox.org/mozilla-central/search?q=%3Cpage&path=.xul. According to https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/page, the xul:page element is "similar to a window, except it should be used for XUL files that are to

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

ch of other shared DOM structures that seem to be in a similar boat. Brian > On Tue, May 14, 2019 at 1:48 PM Brian Grinstead > wrote: > There isn't any particular reason functionally to go to one vs the other but > I think we still generally prefer to get to plain .html i

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

te the html doc conversion. Brian > On May 14, 2019, at 12:37 PM, Boris Zbarsky wrote: > > On 5/14/19 11:32 AM, Brian Grinstead wrote: >>>3. For files where there are no (important) XUL elements in the >>>markup, rename .xul->.html. > > Brian, > >

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

rate ``->``, convert ProcessingInstruction stylesheets to ``, etc). On Tue, May 14, 2019 at 8:24 AM Brian Grinstead wrote: > To prepare for browser.xhtml (bug 1533881 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1533881>), we’ve been > smoothing over differences between XUL documents and c

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

To prepare for browser.xhtml (bug 1533881 ), we’ve been smoothing over differences between XUL documents and chrome HTML documents (bug 1453783 ). We are now working out a plan for removi

Re: Automatically including add_task into SimpleTest.js

This has now landed, so feel free to start using add_task without any extra boilerplate in mochitests. AddTask.js is also now removed so if you had any in-flight patches that were adding tests using it please remove the

Automatically including add_task into SimpleTest.js

This came up in https://groups.google.com/d/msg/mozilla.dev.platform/eptWENSn4wM/sjCWfj1LBwAJ: > On Apr 1, 2019, at 12:38 PM, Brian Grinstead wrote: >> On Apr 1, 2019, at 12:15 PM, Boris Zbarsky wrote: >> I do have one other question on the templates: for mochitest-plain, ad

Re: Creating a new mach command for adding tests

specify the document type (you generally shouldn’t need this since it will detect from the path) If you’d like to add support for a new suite or find bugs / missing features, please block Bug 1540285. Brian > On Apr 1, 2019, at 11:36 AM, Brian Grinstead wrote: > > Based on my o

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

> On Apr 8, 2019, at 8:55 PM, Cameron McCormack wrote: > > On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote: >> I'd like to rewrite markup in the tree to avoid using the [type] >> attribute on

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

Thank you. I will update the script(s) to use that list. > On Apr 9, 2019, at 7:52 AM, Kartikaya Gupta wrote: > > On Mon, Apr 8, 2019 at 11:39 PM Brian Grinstead > wrote: >> I've prepared a script that rewrites this across the tree. The script and >> the g

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

> On Apr 9, 2019, at 2:31 AM, Anne van Kesteren wrote: > > On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote: >> On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote: >>> I'd like to rewrite markup in the tree to avoid using the [type] >>> attribute on

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

The reasoning is: - If we don't rewrite existing test files then it will keep getting propagated in new tests as old ones get cloned. - It's a small cleanup that makes existing tests slightly easier to read (especially when combined with other boilerplate reduction). - I was under the impression

Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

I'd like to rewrite markup in the tree to avoid using the [type] attribute on

Re: Creating a new mach command for adding tests

ml --long-timeout` Brian > On Apr 2, 2019, at 2:40 AM, James Graham wrote: > > On 01/04/2019 23:13, Steve Fink wrote: >> On 4/1/19 11:36 AM, Brian Grinstead wrote: >>> Based on my own experience and discussions with others, the workflow for >>> adding new mochitests

Re: Creating a new mach command for adding tests

y set the type. Brian > On Apr 1, 2019, at 3:13 PM, Steve Fink wrote: > > On 4/1/19 11:36 AM, Brian Grinstead wrote: >> Based on my own experience and discussions with others, the workflow for >> adding new mochitests isn't great. Commonly, it looks like: "copy/pa

Re: Creating a new mach command for adding tests

ple that from this command if possible :). Brian > Cheers, > > Jared > > > On Mon, Apr 1, 2019 at 11:36 AM Brian Grinstead > wrote: > Based on my own experience and discussions with others, the workflow for > adding new mochitests isn't great. Commonly,

Re: Creating a new mach command for adding tests

> On Apr 1, 2019, at 12:38 PM, Brian Grinstead wrote: >>> Links to bugs/comments/etc can be added in the test if they are relevant, >>> but I don't know that it's important enough to add another step in front of >>> getting a useful test case built. I

Re: Creating a new mach command for adding tests

te, but removing it seems reasonable to me, fwiw. > > One small feature request: could you add some basic usage documentation to > the firefox-source-docs as part of this patch? I'm sure I'll forget the > right sequence of commands in between uses ;-) > > Cheers,

Re: Creating a new mach command for adding tests

> On Apr 1, 2019, at 12:15 PM, Boris Zbarsky wrote: > > On 4/1/19 2:36 PM, Brian Grinstead wrote: >> When you run the command it will create a file with the appropriate >> boilerplate and add it to the manifest file (chrome.ini, mochitest.ini, >> browse

Creating a new mach command for adding tests

Based on my own experience and discussions with others, the workflow for adding new mochitests isn't great. Commonly, it looks like: "copy/paste a test in the same directory, add the new test to the relevant manifest file, empty out the actual test bits, write your test". In my experience this i

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

Would this apply to talos as well? I’ve wondered before if we should care at all about opt-only talos regressions for platforms where we ship PGO. IME quite a number of talos changes (both improvements and regressions) only show up on one or the other, so dropping one would simplify things. Bri

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

Artifact builds don’t work with PGO, do they? When I do `-p all` on an artifact try push I get busted PGO builds (for example: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f8ead55ca97821c60ef38af4dec01b8bff0fdf3&selectedJob=219655864). What's needed to make it work? Requiring a full

Re: Bypassing about:home/privacy page loads on new test profile builds via mach

Thanks for the list, that looks like a nice set of defaults. I wanted to add a few related things: - In addition to setting prefs via machrc you can use `--setpref`. For example `./mach run --setpref browser.newtabpage.enabled=false` which would then override the value in your machrc file. Both

Re: Intent to implement and ship: HTMLMarqueeElement

14, 2018, at 5:29 PM, Karl Dubost wrote: > > > > Le 13 oct. 2018 à 02:56, Brian Grinstead a écrit : >> Summary: […] I intend to implement and ship HTMLMarqueeElement. > > Very cool. And a support on that, from a webcompat standpoint of view, > because it seems a lot

Intent to implement and ship: HTMLMarqueeElement

Summary: Motion is a key component of modern web design, and is the premier... just kidding. Gecko currently ships as an HTMLDivElement with the web-exposed properties attached via in-content XBL [0][1]. As part of the process of removing in-content XBL, I intend to implement and ship HTMLMar

Re: Browser Architecture Newsletter #7 (S02E02)

> On Sep 20, 2018, at 9:10 AM, Kris Maglione wrote: > > On Thu, Sep 20, 2018 at 09:02:09AM -0700, Nicholas Alexander wrote: >> On Thu, Sep 20, 2018 at 7:25 AM smaug wrote: >>> > I'm reminded of https://bugzilla.mozilla.org/show_bug.cgi?id=618912 but >>> > IIRC there were similar experiments ba

Re: XUL Overlays Removed

> On Jul 13, 2018, at 3:05 PM, Frank-Rainer Grahl wrote: > > > This is just one piece of the broader XUL removal effort, but it does > > highlight that things can be simpler in a post-XUL world. > > Well I agree that cleaning up overlay usage was overdue. Otherwise the simple > post XUL worl

Attempting to define XUL removal

Removing XUL has been talked about for a long time, but I think it means different things to different people. Since I’ve spent some time working on XUL-related projects I’m going to summarize what it means to me as a way to share what’s currently planned and to get feedback. XUL is a collectio

Re: Proposal to replace the NS_ASSERT function in JS with console.assert

et me know. Thanks, Brian On Mon, Feb 26, 2018 at 10:24 AM, Marco Bonardo wrote: > On Mon, Feb 26, 2018 at 7:02 PM, Brian Grinstead > wrote: > > console.assert doesn't throw an exception, and neither does NS_ASSERT. > So I don’t think replacing consumers with exceptions is cor

Re: Proposal to replace the NS_ASSERT function in JS with console.assert

reat. > > console.assert may be a good replacement, we can leverage the existing > bug to use that instead of simple exceptions. The bug is currently > proceeding slower than hoped. > Does console.assert also throw an exception? > > Cheers, > Marco > > > On Mon

Proposal to replace the NS_ASSERT function in JS with console.assert

There have been some improvements to the console API for chrome callers recently: * The WebIDL implementation is available as a global in JSMs - no need to import Console.jsm (bug 1425574) * Chrome console API calls print to stdout if "browser.dom.window.dump.enabled" is true (bug 1439686) * `c

Re: Proposal to remove the xpfe autocomplete bindings and the xpfe/components/autocomplete directory

This has now landed - it was moved into comm-central in Bug 1418512 and removed from mozilla-central in Bug 1417119. Brian > On Nov 14, 2017, at 9:25 AM, Brian Grinstead wrote: > > That makes sense. I went ahead and filed Bug 1417119 for the removal from > m-c, and we can coord

Re: Proposal to remove the xpfe autocomplete bindings and the xpfe/components/autocomplete directory

ating moving them to comm-central. There is also corresponding css in > the tree. > > Regards > Frank-Rainer Grahl > > > > > Brian Grinstead wrote: >> While tracking down the XBL bindings in the tree, I noticed that there are 4 >> inside the xpfe/ directo

Proposal to remove the xpfe autocomplete bindings and the xpfe/components/autocomplete directory

While tracking down the XBL bindings in the tree, I noticed that there are 4 inside the xpfe/ directory at https://github.com/mozilla/gecko-dev/blob/master/xpfe/components/autocomplete/resources/content/autocomplete.xml. I'd like to remove those bindings, and AFAICT we aren't using them in Firef

Re: De-XBL Plans

> On Oct 22, 2017, at 3:35 AM, smaug wrote: > > On 10/21/2017 11:45 PM, Yura Zenevich wrote: >> I would also like to bring to the team's attention another force worth >> being on the radar (in terms of "forces on the system") - accessibility. >> One theme that seems to consistently happen with r

Re: Using the accesskey attribute with HTML elements in browser chrome

> On Jun 19, 2017, at 6:58 PM, Ehsan Akhgari wrote: > > On 06/19/2017 04:28 PM, Brian Grinstead wrote: >> I was wondering what would need to be done in order to use the accesskey >> attribute on HTML elements in the browser chrome. Here are some of the >> differenc

Using the accesskey attribute with HTML elements in browser chrome

I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far: 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribut

Re: Deprecating XUL in new UI

A few things we had to handle when going through this process for the devtools UI: 1) Already mentioned to but for panels we added a new module that falls back to XUL panels for now 2) For context menu handling we we added a new module similar to the Menu API from Electron that falls back to an

Re: Deprecating XUL in new UI

You can still use dtd files in XHTML as long as it’s chrome-privileged. A lot of the about pages are doing this (aboutNetError.xhtml and others: https://dxr.mozilla.org/mozilla-central/search?q=path%3Axhtml+dtd). Brian > On Jan 17, 2017, at 3:34 AM, zbranie...@mozilla.com wrote: > > One more

Re: Intent to remove: Error Console

Filed bug 1278368 to remove the code and bug 1278372 to remove the component from bugzilla. Brian > On Jun 8, 2016, at 7:57 AM, Benjamin Smedberg wrote: > > \o/ > > Is there a bug to track this code removal? > > --BDS > > On Mon, Jun 6, 2016 at 4:04 PM, Brian G

Re: Intent to remove: Error Console

ved. I suggest a mass-closure with a comment to re-categorize it into Developer Tools: Console if they are also applicable to the Browser Console. > -- Emma > > On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead > wrote: > There is an Error Console feature in toolkit that&#

Intent to remove: Error Console

There is an Error Console feature in toolkit that's been replaced by the Browser Console. We'd like to remove associated code in toolkit/components/console/ and the component in bugzilla (Toolkit: Error Console). This will also remove the —jsconsole command line flag for consumers that don’t

Re: help:browser tool box debugger is not stopped

(moving over to the developer tools list) Thanks for reporting this - I’ve heard about a couple of issues similar to this lately, but haven’t been able to reproduce it myself so another data point is great. Do you see the problem both with and without e10s enabled? Also, does it happen on a c

Re: PSA: Cancel your old Try pushes

> On Apr 15, 2016, at 12:44 PM, Jim Blandy wrote: > > On Fri, Apr 15, 2016 at 12:36 PM, Jonas Sicking wrote: > >> We could also make the default behavior be to cancel old pushes. And >> then enable push message syntax for opting in to not cancelling. >> >> > This could be very frustrating (a

Re: Dominator tree memory analysis now in Nightly

> On Jan 14, 2016, at 3:01 PM, Nick Fitzgerald wrote: > Also, what is the plan for making tools like the Memory view appear in a > default install? In other words, without having to go to the Settings. I > worry that users may not know to click on the Settings and just think that > other brows

Re: Dynamic Logging

> On Jan 8, 2016, at 5:50 PM, Mike Hommey wrote: > > On Fri, Jan 08, 2016 at 05:32:48PM -0800, Eric Rahm wrote: >> Hi Folks- >> >> With bug 1233881 we >> landed the ability turn on logging via prefs. >> >> Lets say you have a log module "F

Re: Intent to ship: Service Workers with FetchEvent

Also, webconsole logging for Service Workers is preffed behind devtools.webconsole.filter.serviceworkers, which will be enabled by default in https://bugzilla.mozilla.org/show_bug.cgi?id=1201962. Brian > On Nov 20, 2015, at 10:34 AM, Ben Kelly wrote: > > In Firefox 44 we intend to enable Serv

Re: Intent to remove: mochitest- mach commands

Does this include subsuites like devtools? There is currently a bug on file in which `mach mochitest` doesn’t work with devtools tests (1122590). Until that is resolved, if mochitest-devtools was removed then running these tests would become the harder-to-remember `./mach mochitest browser/dev

Re: what is new in talos, what is coming up

The upcoming changes sound great! Is there currently a way (or plans to add a way) to track regressions / improvements for a single measurement within a test? I see that in perfherder I can add these measurements to a graph (http://mzl.la/1E17Zyo ) but it’s hard to disti