I was hoping that other types could be added over time, so making the name
generic was intentional. It will already error if you try to add something that
doesn’t look like a mochitest, but it’s a good suggestion to make that more
obvious. I can file bugs for other test types and then include
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/paste a test in the same
directory, add the new test to the relevant manifest file, empty out the actual test
On Mon, Apr 1, 2019 at 1:03 PM Emilio Cobos Álvarez
wrote:
> On 01/04/2019 21:40, Bobby Holley wrote:
> > My (possibly outdated) understanding is that the sccache distributed
> > compilation stuff is restricted to the build machines we control.
> Naively,
> > I'm not sure there's a secure way to
On Mon, Apr 1, 2019 at 12:23 PM Emilio Cobos Álvarez
wrote:
> Hi,
>
> Over in #layout people were ranting about how much of a pain it was to
> set up icecc on MacOS. I pointed out that sccache in theory does support
> distributed compilation[1] and in theory also supports MacOS clients.
>
> Does
On 01/04/2019 21:40, Bobby Holley wrote:
> My (possibly outdated) understanding is that the sccache distributed
> compilation stuff is restricted to the build machines we control. Naively,
> I'm not sure there's a secure way to have machines in the wild contribute
> build artifacts, given the risk
> On Apr 1, 2019, at 11:54 AM, Jared Hirsch <6...@mozilla.com> wrote:
>
> This sounds great! I land features in the tree periodically, but infrequently
> enough to forget lots of little details. It would really save time (mine and
> the time of people I ping on IRC for help...) if our tooling
> 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 did also consider adding a TODO comment
> On Apr 1, 2019, at 12:23 PM, Felipe G wrote:
>
> Something that would be a nice flare would be if it got the information from
> the moz.build file to tell which component the new file would be related to.
>
> Definitely not essential, though.
I think that would be doable, though I don’t
My (possibly outdated) understanding is that the sccache distributed
compilation stuff is restricted to the build machines we control. Naively,
I'm not sure there's a secure way to have machines in the wild contribute
build artifacts, given the risk of malicious code.
It seems plausible that we
> 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,
>> browser.ini depending on the type).
>
>
Hi,
Over in #layout people were ranting about how much of a pain it was to
set up icecc on MacOS. I pointed out that sccache in theory does support
distributed compilation[1] and in theory also supports MacOS clients.
Does anybody know to what extent is it in a usable state? Can it replace
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,
browser.ini depending on the type).
Brian, thank you for putting this together!
I have one concern with the
This sounds great! I land features in the tree periodically, but
infrequently enough to forget lots of little details. It would really save
time (mine and the time of people I ping on IRC for help...) if our tooling
simplified the process of creating new tests.
I don't have any historical context
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
Summary:
In bug 1386214 we are planning to remove the Code for the "require-sri-for”
CSP directive.
The “require-sri-for” directive allows developers to block resource
requests that do not contain integrity metadata.
Please note that the entire code has always been behind a pref
An update on the bug type and regression fields:
Because of Firefox 66 and the subsequent 66.0.1 pwn2own chemspill, we decided
to delay the deployment of the change. We are now ready to deploy the new bug
type and regressions/regressed-by fields to production Bugzilla later this week.
A
Due to unexpected circumstances, we couldn’t deploy and migrate the bug type
field this week. Will try again next week as soon as on Monday.
Thanks,
-Kohei
On 2019-03-26 8:05 p.m., Kohei Yoshino wrote:
An update on the bug type and regression fields:
Because of Firefox 66 and the subsequent
Hi, I am trying to fix Bug 1529182,[1] but debugging the SVG
code is particularly difficult for me because it uses at least six
coordinate spaces, and I can't figure out how they relate to each
other:
- Run space
- Run user space
- Frame user space
- (Regular?) user space
- GFX space
- App space
On Fri, Mar 22, 2019 at 1:55 PM wrote:
> Hi Ehsan,
>
> Thanks for the follow up.
> I don't have access to a macOS computer with that 12.0.3 version of Safari
>
> On the other hand I have access to Google Analytics data for multiple
> sites, not the top 100 Alexa, but I don't see any evidence of
Hi Rik,
Sorry for the late reply.
On Fri, Mar 22, 2019 at 10:10 PM Rik Cabanier wrote:
>
>
> On Fri, Mar 22, 2019 at 6:07 AM Ehsan Akhgari
> wrote:
>
>> On Thu, Mar 21, 2019, 9:39 PM Rik Cabanier, wrote:
>>
>>> Why are these sites not included in the "safe browsing" service that is
>>> used
Are there also plans to revisit our longstanding
foreground/background/link/visited-link colouring prefs (as well as
their companion use_system_colors pref) in light of this set of changes?
They've never really worked very well, nobody has really taken on fixing
their UX, and it would be nice
Hello,
Sorry for the spam. Forgot to mention the bugs from github.
Here's the list of new issues found and filed by the Desktop Release QA
team in the last 7 days.
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
Hello,
Here's the list of new issues found and filed by the Desktop Release QA
team in the last 7 days.
Additional details on the team's priorities last week, as well as the
plans for the current week are available at: https://tinyurl.com/y4n4rovw.
Bugs logged by Desktop Release QA in the
23 matches
Mail list logo
