What is the git cinnabar github compatible repo again?

jya: see github.com/glandium/git-cinnabar/wi…-git-workflow-for-Gecko-development

jya: or wiki.mozilla.org/GitHub/Gecko_Repositories maybe

heycam: yeah, I know that one, don't want to check out with cinnabar though.

It always times out for me on big pull.

I am seeing "A web page is slowing down your browser." message repeatedly, maybe it's the cause of the irresponsibility.

jya: the instructions in github.com/glandium/git-cinnabar/wi…-git-workflow-for-Gecko-development mention a faster way to do an actual cinnabar checkout

glandium gave me that work around. Basically pull from the repo.

If I have more than 10000 commits to pull, it will time-out for me, regardless of the machine I use and the internet connection I'm on, whichever location I may be.

The other advantage of pulling from. The cinnabar compatible clone, is that I don't have to install and configure cinnabar. I'll do so automatically when I'll first run mach bootstrap

jya: it shouldn't time out anymore

that was due to changes to a file that is not in the tree anymore

jya: also the new faster way clones from github directly

glandium: it did just yesterday as I was fetching release

the git -c cinnabar.clone=github.com/glandium/gecko clone hg://hg.mozilla .org/mozilla-unified mozilla-central && cd mozilla-central way?

jya: you'd need to give more details

jya: yes

also, I pulled on my machine that hadn't been updated since December, there was 12000 commits , always the same error, so in the end i do it 3000 commits at the time

I mean the error are always the same and haven't changed for the time I've been experiencing those issues. Now I've changed country and it's still happening :(

cloning with the new way. i'm maxing out my link which is cool

jya: the file was removed recently-ish, so it's plausible that your tree was just too old

why would it fail only with big pull, but succeed when doing 3000 at a time?

jya: because it's a function of the number of changes to that one file

how much overhead does that add cloning the two at once like that ?

cloning the two?

i mean using the cinnabar clone from your repo, plus the unified ?

(don't know the advantage of using unified over central)

unified has all the branches, including esr, release, and beta

ah cool

though I just had all the repo in my .git/config set up

so could pull that way

glandium: clone is finished, this is the fastest pull I've ever done, it usually ran in multiple amount of hours

So, I'm now getting "you've launched an older version of Firefox" when I started a 67.0a1 inbound local build, against one of my main "testing" profiles (which is always used with builds against inbound). It's possible the changeset for this repo is older than the other one... but both are 67

It was inbound rev 456213 (Jan 31st); the other repo used with the profile was inbound dev 457186 (Feb 5th)

glandium: in my existing mozilla-central checkout, after adding a "unified" remote (pointing to mozilla-unified), can I do something like

git -c cinnabar.clone=github.com/glandium/gecko fetch unified

or maybe git -c cinnabar.fetch=github.com/glandium/gecko fetch unified

jya: no

must re-clone the whole lot?

no, just git remote update unified

cause attempting to fetch release right now (need to uplift a patch) I will get timeout, always

yeah, but doing that fetch 54263 changeset, and when it goes to "reading and importing XXX manifests" I'll get a timeout

jya: can you paste the output of git cat-file -p refs/cinnabar/metadata^ ?

maybe time for me to ditch my setup of having multiple remotes and use unified all the way

would I still be able to push to inbound, or will still need another remote? (I'm guessing the later)

the latter

jya: what's your OS?

right now I'm on Windows

most of my timeouts occur on windows because I seldom use it

jya: that looks like a clone of mozilla-central with maybe a few other branches?

this is indeed a clone on mozilla-central

and pulling release times out?

yes.

at what point does it time out?

I can start it and give you the exact error message in about 30 minutes

when it has done about 25000 manifests

30 minutes?!

yeah, about that

git cinnabar --version

jya: try setting cinnabar.experiments=store-manifest and pull release again

command?

git -c cinnabar.experiments=store-manifest remote update $remote

IIRC, you got me to do that last time, and it didn't make a difference. but happy to try anything. Every time I come back on windows, i hit this issue and it takes me hours to get around it:(

started, takes about 1s for every 220 manifests, there are 59928 changesets to go

jya: does that feel faster than before?

it does

and it's already done 30000 manifests

(I had timed for 10s before)

glandium: ah same deal

full output:

jya: try again with cinnabar.experiments=store-manifest,wire

jya: can you graph your network throughput during the operation?

glandium: last time you told me it was my connection and there was nothing we could do about it. I've had this occur in Mozilla Paris, Mozilla Portland, at home in France (gigabit fibre with orange), 4G mobile and now home in Australia on a new 100/40 internet

sure

btw, it's only on windows

reading and importing XXX manifests doesn't touch the network.

well, that got me curious ttps://hg.mozilla.org/releases/mozilla-release

that's not a valid url!

ah yes it is :(

rstrong: ping

CosminS|sheriffduty: hi

glandium: almost done with the reading and importing manifests page, there's been close to 0 network activity during this time, only during the first 3-4s

jya: and how much time has elapsed?

(between the last activity and now)

rstrong: do you think this rise in xpcshell failures from here treeherder.mozilla.org/#/jobs?repo=…27bc903c00011&selectedJob=227069582

about 10 minutes

could have smthg to do with your changes?

I started the update at 18:09

jya: it would seem windows is more aggressive at buffering

yep, right after the manifests reading completed, the Reading and importing 30239 revisions of 4978 files started and failed almost instantly

and no activity then

and treeherder.mozilla.org/logviewer.ht…05195&repo=autoland&lineNumber=6075

I mean the max of the graph is at 100Kbps

that's probably me talking here

jya: yeah, what happens is that until the buffered data from the initial network traffic is exhausted, things go normally, but when fresh data is needed form the server, the server is ejecting you

so my work around for that is to go on the web interface, go back -60000 commits, and then do git cinnabar fetch release SHA1_10000_at_a_time

if that fails I go 3000 at a time etc

buffered where?

OS level, presumably

CosminS|sheriffduty: each xpcshell tests run in their own process for the test so no, I don't see how that could be caused by the patches I landed.

I do have 128GB on that machine, but I find it hard to believe it would cache at the OS for that long

rstrong: thanks

but what do I know..

though, right after a reboot is typically when I go to fetch

CosminS|sheriffduty: looks like they started on the push prior to my push?

it shouldn't be buffered yet if it's never been fetched earlier right?

rstrong: that was my first hunch too

what to have all covered, thanks for responding

no problem... I left irccloud logged in on my phone so I get pings

jya: the problem is that, say, windows buffers 2MB raw, and it takes multiple minutes for cinnabar to process 2MB (considering delta compression + compression, it's actually not so far-fetched), it can go multiple minutes without any need to fetch new data from the network

jya: it's probably more than 2MB, though

glandium: could we have dummy connections that only keep the thing alive.?

I'm going to reclone the whole thing, this taking the unified repo and using the method of fetching cinnabar stuff from your repo.

jya: you can avoid recloning by doing git cinnabar rollback 0000000000000000000000000000000000000000

that will reset all cinnabar metadata

Why would that help doing the next fetch?

jya: if you reset, you can use the fast clone thing on a fetch

glandium: the fast clone "thing" works with the release repo?

jya: no, but if you do it with unified, you get the release branch

ah ok

should I just get unified and work from there from now on?

jya: maybe? but make sure not to use branches and use bookmarks instead

why that?

because branches/default/tip switches between release, esr, beta, inbound, and central

whichever was pushed last to

is there a guide on what do do if say I want to look at release?

use bookmarks/release

or still use the release remote

tbh I don't know what bookmarks are with git

which you'll have to do if you want to manually push there

jya: they're branches with a different name

and then I would have first to pull from the release repo

jya: you'll always have to pull from the release repo, in case unified is behind

how far behind is unified usually?

not much

minutes max

so for release shouldn't be a problem

glandium: bugzilla.mozilla.org/1015547#c15

peterv: same conclusion

right

hsivonen: did you reproduce the 2018 edition problem in a workspace+vendoring setup that is not mozilla-central?

glandium: not yet

hsivonen: that would probably help

glandium: indeed. I know almost nothing about workspaces, so I don't really have an idea of what could be relevant for repro

hsivonen: that said, did you check there aren't other invocations of rustc for packed_simd? I've seen weird things that I need to debug about what appears to be some crates being built twice

glandium: I didn't. I just looked at the Gnome System Monitor and hoped it updated frequently enough

glandium: what tool should I use to dump all process creation command lines?

hsivonen: strace -f -e process -s 10000

-o log

glandium: where "process" is "rustc"?

no, literally process

that traces all syscalls related to process management

glandium: thanks

whoa. slow build is slow with this one

strace is heavyweight

glandium: In order to avoid excess slowness, I straced only a re-invocation of mach build after the failure to catch it failing the incremental build

there's an invocation of /home/hsivonen/.cargo/bin/rustc followed by /home/hsivonen/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc

glandium: I gather the former is the rustup binary itself redicting to the second real binary

glandium: both have --edition=2018

hmm. some options are --foo=bar and some are --foo bar

let's see how --edition works in a standalone build

passed as --edition=2018 in the standalone case, too

glandium: tried a minimal workspace: github.com/hsivonen/test_workspace . It does not reproduce the problem.

I have a question about wpt. How can I run wpt under testing/web-platform/mozilla/tests with |./match wpt product --chrome|? It claims that "Unable to find any tests at the path(s)".

oops, |./mach wpt --product chrome|, I meant.

dmajor, what would you recommend to do exploratory profiling on Windows 10 ?

like, I know there is an issue but I don't know where

are there guidelines/howtos for introducing a new pref?

freddy: no afaik. anything specific in mind?

I'm adding code that shouldn't run unless a pref is set :-) that pref is new

I'm just gonna look at patterns from other patches. there are enough. :)

padenot: personally I use Windows Performance Analyzer. others may recommend Gecko Profiler.

dmajor, ot

dmajor. it's scary, but I think it'

s finally time I learn this set of tools

ETW and xperf and those things

gecko profiler doesn't work for me because I wouldn't know which thread to capture

padenot: I don't know if it's any comfort, but it used to be so much worse back when it was called xperf :)

I'm spoiled by tracecompass on linux and instruments on osx unfortunately, it's going to be hard, but it's not like there is a choice here

and gecko profiler of course, which is amazing when it can be used

padenot: this is probably the best collection of guides tinyurl.com/etwcentral

dmajor, yes, i've been reading quite a few blogpost from this guy, he has amazing stories sometimes

dmajor, thanks for this

now if my vsc++ redist install would finish it would be amazing

padenot: let me know if anything seems too complex and I can tell you what parts to ignore :) it's one of those things where the basics will get you a long way but then there's a bunch of extra situation-specific tricks

right

I'll have a go at it, and ping if I face issues

what I'd like is something like lttng where I can know, for example, what caused a thread to be de-scheduled, or what thread was in the queue for a mutex, how long it was taken, that kind of things

but simply a good sampling profiler I can trust would nice, for some other stuff

padenot: for simple "using too many cycles" there's "CPU usage (Sampled)" but for the threading-related stuff, "CPU Usage (Precise)" is very good randomascii.wordpress.com/2012/05/1…t-xperf-documentationcpu-scheduling

ok, reading this one first

Is there an issue with treeherder?

Looks like I’m seeing a 500 attempting to get push data

Standard8: wfm. any special push in mind?

Aryx: treeherder.mozilla.org/#/jobs?repo=…ed8b56238c79f9a13aa639f498101926bc4

specifically treeherder.mozilla.org/api/project/…ed8b56238c79f9a13aa639f498101926bc4

is the one that gives 500

treeherder.mozilla.org/#/jobs?repo=…a28be6db6c67c9d3b49aa38ede46939e734 works

wants a fromchange?

Aryx: huh, dunno where that tochange came from, can you try this one treeherder.mozilla.org/#/jobs?repo=…ed8b56238c79f9a13aa639f498101926bc4

oh

Aryx: oh, I think I see, something posted the wrong link on the bug

Standard8: can you link me to that? th removed the non-pushhead changeset support in the url

went through hgmo, that automatically picks the correct revision

Aryx: bugzilla.mozilla.org/1526228#c2 - I think that was posted automatically when I did ./mach try in hg repo

Standard8: ok, needs either fixing in th or a bzext update

will create a bug

thanks

nbp: we're cancelling this friday meeting, right?

afk

myk: ping

jorendorff: right

dylan: Is there a way I can disable Markdown for a particular comment?

ato: begin the comment with #[markdown(off)]

if you want monospaced text, use ```\n````\n fences.

dylan: OK, thanks.

jesup: pong

myk: I have a patch to improve responsiveness testing in the profiler (by directly measuring Dispatch->execute times). This means adding dispatchTime TimeStamp attribute to nsIRunnable - and that's breaking your recent addition of moz_task:

myk: paste.rs/w54

Either we have to move moz_task to be built on Runnable (or the UnnamedRunnable I'm adding, probably), which implements Get/SetDispatchTime, or we need to teach it's runnable impl to implement those within moz_task

jesup: we're going to make every runnable bigger? just on nightly, or release/beta too?

also not enthused about more vtable entries times 2000 vtables

jesup: maybe you could land the "get everything deriving from Runnable" and then we could talk about the direction to go from there

froydnj: we can limit this to nightly/beta, like with do with the named stuff. That would mean we wouldn't get data in profiles on release builds (or I find another way to do it, which perhaps i can do - we talked about this last fall-ish which is why I went this way (just unbitrotted and finished the initial patch). It keeps CPU overhead down by only touching the dispatchtime stuff if the...

...profiler is on

I can split into nsIRunnable->Runnable/UnnamedRunnable, and a patch to implement responsiveness

myk: is it just that moz_task doesn't implement the attribute? and if so, can it? (takes a TimeStamp)

jesup: hmm, unsure; can you point me at the patch?

myk: bug 1482244

applies against inbound from last night

froydnj: let me split, and also re-evaluate alternatives (like having a separate array where we track event dispatch times, and only populate it when the profiler is on)

jesup: I think we want everything to derive from Runnable for other reasons, so that work is valuable in its own right

jesup: tracking dispatch times in the queues themselves sounds like an interesting alternative

yes; that was my initial alternative when I started looking at this

jesup: also, if you required everything in terms of Runnable, then all the thread interfaces could be moved over to work in terms of Runnable, not nsIRunnable, and then your Get/Set methods could at least become non-virtual

This was slightly simpler (I thought... then I realized I the number of nsIRunnables...)

froydnj: yes, that's right. My patch removes all but one or two nsIRunnables right now (and myk's new rust one)

and I'm sure we could remove the rest

Is there a way to load a js script that is actually an ES6 module from a chrome js context? Kind of like <script type="module"> but manually

froydnj: right now I have a new class "UnnamedRunnable", since there were a lot of unnamed runnables out there; I could just give names (class names probably) to all the unnamed ones instead. but we can discuss that in review

gets rid of a lot of ::GetName() methods too :-)

jesup: no, moz_task can't implement the dispatchTime attribute for the reason given in the build error ("Rust only supports [ref] / [ptr] native types"), which is a limitation of the Rust-XPCOM bindings

froydnj: patch is split, and up for feedback to you (the -> Runnable part)

myk: so.... if we do decide to add an TimeStamp to runnable, what do we do? also, even if we don't add the attribute, we may be moving all the nsIRunnable uses to Runnable for the thread interfaces - which we started and half-completed around the 57 time. Since moz_task uses nsIRunnable....

froydnj: the patch only hits ~125 files or so ;-)

jesup: tiny

yeah. (and pretty mechanical, though there are some exceptions). emacs macros FTW

Fallen: afaik, script loading currently depends on/needs a document, so not from chrome directly

*es module loading

would the xul document work?

idk

I found a bug that suggests there is no way to do it right now

Gijs: So ....

Gijs: Are you around?

mossop: So, I'm now getting "you've launched an older version of Firefox" when I started a 67.0a1 inbound local build, against one of my main "testing" profiles (which is always used with builds against inbound). The changeset for this repo is older than the other one... (Jan 31 vs Feb 5) but both are 67

Gijs: Have some questions about preallocated about:newtab

It was inbound rev 456213 (Jan 31st); the other repo used with the profile was inbound dev 457186 (Feb 5th)

jesup: What matters is not the revision it was built from, but the build id. Though I have been wondering if we should just bypass this entirely in development builds

do buildids have to be increasing?

that's a real annoyance if you have multiple builds. Even debug and opt of the same repo/rev

They are expected to be, by default they are generated based on the build time

yeah, but if I have a repo, build debug, build opt, now I can't even switch between them

Also: what if a X.0.1 sec release has a problem, and you need to go back to (or try) X.0?

or "can you try that in X.0b(N-1)?"

Yeah, we're wrestling with this question, probably going to be a meeting next week to figure out where we should stand

aosmond: My shaky-text-on-reddit bug is related to being scrolled to the exact middle of the page and the scrollbar itself wiggles in size... Suggests more likely layout than graphics?

So I'm screwed until then? ;-) :-/

There isn't even an override as best I can tell

jesup: --allow-downgrade

(also happens with or without webrender)

Definite echoes. ;)

bz: :-)

The combination of -profile and --allow-downgrade sounds like the "I take my life into my own hands" mode we were operating in before and you want now. ;)

--I-accept-the-consequences

--on-my-head-be-it

it will be annoying, though since normally I type my ./firefox commands by hand

bz, jesup: Definitely taking notes over how this is impacting folks. JoeH is very much "block any downgrade by default" and QA are pushing for some method of downgrading. We're going to try to figure out soon where we want to end up on that line

Mossop: makes sense

Mossop: I think what's best for our users at large may well not be what's best for developers or serious QA

Is it a downgrade if it's the same release number? (yes, a change *could* have landed and created an incompatibility -- how often, if ever, would we uplift such a change to beta - let alone release?

Mossop: I'm not sure whether we need anything more than the existing override, btw

mossop: For the developer/QA population

jesup: On nightly yes, but as you say, less likely on beta and release

My concern is we may bite ourselves with users if it's purely build-date (such as the beta N-1 thing, especially if beta N has a bug that causes a problem for people)

jesup: (waylaid by meeting) unsure what we do if we add TimeStamp to nsIRunnable; i don't think there's a simple fix for the Rust-XPCOM binding limitation, or nika would've implemented it in the first place; and if we move all nsIRunnables to Runnable, then it also isn't clear to me how we proceed; would need to dig into the details

myk: Hmm?

I thought the point of this was to stop users from downgrading releases (67->66, or 67 beta to 66 release, 68 nightly -> 67 beta, etc)

myk: my name was mentioned

nika: starting around 11:09 EST here

jesup: So, the issue is that you want to implement an interface using Rust-XPCOM which has some weird native methods on it?

jesup: Specifically it looks like something returning a `TimeStamp`?

nika: jesup has a patch to add a TimeStamp attribute to nsIRunnable, which fails because moz_task now implements that interface, and "Rust only supports [ref] / [ptr] native types"

Mossop: I'd be fine if Nightly was handled differently than beta/release; we should never uplift an incompatibility to those without some real consideration (if ever). So on beta/release, major-rev-number should be good enough. On Nightly, we should (IMHO) do no more than warn about buildid downgrades.

myk: Ah yes

myk: This is one of the limitations of the way that rust-xpcom works out.

and even if we don't add it, we're talking about making the xpcom thread api's take Runnables instead of nsIRunnables

jesup: How does your code handle JS-implemented interfaces?

it's [noscript]

sure, but when js implements the interface, it will give a `NS_ERROR_NOT_IMPLEMENTED` or something like that when called, is that OK?

sure

One option here would be that I could support NS_ERROR_NOT_IMPLEMENTED return values for unsupported rust methods

So you can implement an interface with incompatible methods, but everything else throws

froydnj: how does JS-implemented Runnables (or what Nika refers to, which are still nsIRunnables, not Runnables) affect your thoughts on the thread API?

i would imagine we'd need to have js-implemented runnables be special objects subclassing Runnable, and use custom conversion logic

rather than the default XPCWrappedJSObject

Which TBH may be a reasonable idea either way

We might sidestep much of this by not putting this in Runnable/nsIRunnable, and implement shadow arrays for the event queues

though perhaps froydnj has other reasons to move to Runnable

in any case, the first patch on that bug will get us basically to the point where there are few if any nsIRunnables in c++

which was started as part of quantum dom/etc IIRC

jesup: nika's idea (JS things either subclass, or we wrap JSRunnables in Runnable) were what I was thinking of doing

froydnj: ok

(my first thought would not have been to modify xpconnect, but nika is much smarter/braver than I am)

s/smarter/more naive/

froydnj: The main issue currently is just that nsIRunnables can be plain-old functions in JS-land

nika: would we win any harder by implementing xpconnect magic vs. having nsIRunnable be "JS only" and wrapping those up in a separately allocated Runnable?

better naming logic?

I'm not sure how you'd be doing that?

doing which?

Would we duplicate every method taking nsIRunnable to have two implementations?

One for JS runnables, and one for native ones?

I think so, but ideally that would not be very many places

mostly limited to nsIThread and related, for scriptability

I am not 100% sure we can get away with that

froydnj Hmm, you're right

there aren't many nsIRunnables in scriptable contexts

but I think moving to a world where we have "the C++ interface" and then this JS thing on the side is in some ways better than "JS interface for everything" that we have now...and AIUI what is happening in other places in the tree

nsIEventTarget::Dispatch, nsIPermissionManager::whenPermissionsAvailable, nsIThreadManager::DispatchToMainThread, and nsIMemoryReporterManager::minimiseMemoryUsage

and if we did a "C++-native" interface, we could look at not having QI/AddRef/Release on Runnable, as some people have requested/complained

Those are all 4 scriptable nsIRunnables

(in xpconnect)

(may be more in webidl)

I hadn't even heard of whenPermissionAvailable

Yeah, that one's my fault

is minimiseMemoryUsage scriptable? blah

we should make whenPermissionsAvailable not take a nsIRunnable - it only does 'cause I was lazy

But yeah, I suppose ideally we'd just make nsIEventTarget::Dispatch and nsIThreadManager::DispatchToMainThread not take runnables, but instead just take jsobjects, and then have a wrapper runnable which invokes `Call` on a jsval when it is run

does that mean we can't throw errors when calling Dispatch if you hand it a non-callable value? I assume we would throw in that case today

Well kinda

IIRC it's complicated - if the object is a jsobject, I think we just let you

and the callable will then raise an `NS_ERROR_NOT_IMPLEMENTED` when called

Because when making XPCWrappedJSObject, we don't validate that methods are implemented

yeah

But I think we'd throw if passed a primitive

Which is easy to do

but I don't think that error would ever get seen, because errors from Run() don't really get propagated anywhere

Yeah

What I'm saying is the new logic wouldnt necessarially be worse

in fact we could make it better by checking that the object looks callable explicitly

Huh, I seem to be getting infinite compilation doing an optimized arm build

nalexander: is this something you've seen?

bholley: yes, we have seen compiler flakiness in various configurations, including many ICEs.

bholley: but never a run-away process. You are running Mozilla's clangs, i.e., from bootstrap?

nalexander: yes

bholley: you might ask in #build -- I need to step out -- but I don't know an open ticket for a run-away process.

bholley: on macOS, right? I remember froydnj wondering how tested the macOS clangs were... maybe this jogs his memory?

nalexander: thanks

^ looks like it's plausibly my issue

(I got that by web searching for selectiondag::combine, which is where the profiler shows us spending time)

I guess that latter one is pretty old, but the former is relatively recent

this was with a --enable-debug --disable-optimize build

whereas my --disable-debug --enable-optimize build worked

anyone know if there's an easy way to take a pushlog window (ie between changes X and Y) on hgweb and see the changes to a specific subset of files?

Gijs: I know locally you can do logs at the directory level

something a la benjamin.smedbergs.us/blog/2012-07-…or-changes-between-firefox-releases ?

I believe hgweb can accept revsets too, but haven't ever really played with it

can one use markdown in bugzilla user stories?

Gijs: well, hg log foo/bar, then filter by date I suppose

Gijs: hg.mozilla.org/releases/mozilla-beta/help/revisions, pushdate(interval), not sure what the exact syntax for interval is

or rather by rev:rev

yeah, I managed to do it locally

it turned out the pushlog was wrong, which explained a lot :)

:-)

jmaher: is there a dashboard of all arm64 test failures somewhere? I don't need (but can accept) them broken down by test type. is looking at the dependency tree of bug 1522997 a good approximation?

dmajor: I just look at bugzilla.mozilla.org/showdependency…=1522997&maxdepth=2&hide_resolved=1

dmajor: that is probably 70% of the failures- hopefully you can help get fixes for many of the bugs there

ok, thanks -- I

I'll use that as my source for picking up new investigations

dmajor: we have 1 machine hooked up to try, so if you need to run anything, let me know- itis sort of hacky atm

dmajor: cool; also note, we will have more machines hooked up to try and not have it so hacky in a few more weeks

jmaher: great! maybe by then I'll have more time to look at them :) I meant to start this week but it didn't happen

we should have a better handle on bugs on file for all failures in the next week- timing is working out well :)

dmajor: one area in that list of bugs is there are some webgl/canvas tests that are failing- I am not sure if they are all related- if you know anything about that stuff it would be nice to get context

jmaher: unfortnuately gfx is likely one of the areas where I can be least helpful, but I'll try to take a quick look to see if it's maybe just a superficial thing

a case of your guess is as good as mine probably

whimboo: gandalf: i added a question for both of you on phabricator.services.mozilla.com/D17393

snorp: Do you know the prevalence of media decoding support for Fennec offhand? developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats says things like '[Fennec] supports [h264] in some cases, but only when a third-party decoder is available, and the device hardware can handle the profile used to encode the MP4' but is that 90% of the

time, 99%, 99.9%, etc...

tjr: ah, that's super old

tjr: we should be able to do h264 on every device we run on

I mean I guess it's technically a true statement since we do rely on OS decoder

but it's almost always going to play unless it's some super weird profile (like lossless or something)

Same story with vp9, aac, and the other formats? Everything is supported same as desktop?

tjr: for vp9 we probably end up using a software decoder much of the time

aac is supported by the OS

theora/ogg are software

err vorbis

tjr: h264 is really the only thing we don't have a software fallback for, IIRC, but it has been a while since I really looked

tjr: jhlin is the android media guy :)

stefan_hindli|sheriffduty: were there other candidates for the failure that bug 1525858 was backed out for? I ask because xpcshell tests all run in their own process, the changes in bug 1525858 were entirely app update test only changes, and I have numerous recent try runs (around 4 AM this morning is the latest) where there were no issues.

rstrong: the xpcfailures seem to have started from your push

looks like marAppInUseStageSuccessComplete_unix.js failed or timed out (can't tell since there isn't logging of the parallel run) and succeeded the sequential run. Though that shouldn't pollute other tests the harness might have something that allows it.

stefan_hindli|sheriffduty: it looks like the push immediately before rstrong's is directly related to test_handlerService.js, but rstrong's definitely isn't

mhowell: yeah it looks like it, I'll reland rstrong's push

Thanks mhowell !

stefan_hindli|sheriffduty: thanks for relanding!

rstrong: no problem, sorry for the mixup, I really thought your push was the one responsible for the xpcshell failures.

no worries

😊

florian: ping

or mconley

pong

also pong

florian: trying to understand searchfox.org/mozilla-central/sourc…content/test/performance/head.js#68

florian: any time there is any event, we mark all layout dirty?

(the context here is that bug 1506376 makes already very common bug 1489259 permafail )

yes, the idea is to make the layout dirty before executing any script, so that any time a script does something that _could_ trigger a sync flush, it will trigger it and get caught by the test

(bug 1506376 let's us paint more often if normal priority queue is flooded)

florian: ahaa, so it is like approximation of "script will run"

yes

hey guys, I want to upload a patch to a bug, do I just do "git diff" and then upload the file?

Hi sefeng. You should be able to find some help with that in the #introduction channel.

sefeng: git format-patch is usually a little nicer

But yeh, its that simple ..... for now

kumar daleharvey: thanks!

florian: I'm having hard time to understand how this setup can work with popuppositioned

which is dispatched if reflow is done

should popuppositioned get similar handling as MozAfterPaint

I'm not familiar with popuppositioned

florian: searchfox.org/mozilla-central/sourc…nsMenuPopupFrame.cpp#1606-1609,1614

if ignoring that event fixes the test, it's probably a fine thing to do

florian: ok, let me push to try

(request review from Mike, he's more familiar than me with the reflow part of these tests)

ok

thanks

froydnj: Seems like this is actually wrong: phabricator.services.mozilla.com/di…/?ref=583281&whitespace=ignore-most. On OSX it still ends up with MOZ_HAS_REMOTE defined, it's value is '' though (literally two quote characters)

smaug: :o you just made me realize that's also probably the cause of the weirdness I found when changing how overflow events work

Mossop: ah, yeah, you want `if 'gtk' in toolkit or toolkit == 'windows': return True` and that's it

sorry, I written those kind of tests scores of times

Ah it has to return None to be undefined. Ok

RyanVM: ping

jya: pong

I see you are doing release uplift.

emilio: during testing?

or just this event

I guess the event could cause something weird

since sure something is trying to handle it

and then causing more layout changes..

How big is the window to get bugzilla.mozilla.org/1525230 in?

jya: pretty simple patch - how worried would it make you doing so without it going into a beta first?

RyanVM: not much, otherwise the pref one line change in bug 1520200

Bug 1520200 is theorically safer

jya: pref off returns us to fx64 behavior?

RyanVM: yes (sorry had to park the car)

jya: assuming that's the case (flipping the pref returns us to 64 behavior), I think I prefer that for the dot release given the short window we have here

and the real fix for beta

Me too.

Ok

I'll nominate the pref change for release then.

perfect, thanks

rstrong: it seems that the push I backed out and relanded needs to be backed out again since it has some android failures - treeherder.mozilla.org/#/jobs?repo=…f1f47c8650d8f&selectedJob=227261543

RyanVM: done

stefan_hindli|sheriffduty: those tests aren't even included with android builds or even run on android

I'm curious if the c4 on the push right before yours turn out green

stefan_hindli|sheriffduty: I looked at the log and none of my code is included

Also, android doesn't use toolkit's app update at all.

Nothing under toolkit/mozapps/update/ is included by android

rstrong: That's not true on nightly, though it will be soon (bug 1520248)

Mossop: Actually it is true. I almost replied to that thread because of people thinking balrog and app update are synonymous. Android / fennec used app update several years ago but they decided to create their own update mechanism that doesn't use any of toolkit/mozapps/update/.

Oh, huh

They didn't even create a new define which caused a few problems at first

rstrong: so it looks like your push is causing those c4 failures

stefan_hindli|sheriffduty: truly, there is no way it could. The code isn't included with android and hasn't been for many many years.

yeah, it looks like your push is ok, it's the one before yours that seems to cause this

I verified again that the code I landed isn't in that build

I already backed that out so we should be fine

eh, sorry for wasting your time

There you go... no worries. I'm actually laughing a bit deliriously about it since I've only had a couple of hours sleep

yeah, you and me both, I guess it's one of those days :))

Could anyone point me towards the correct mechanism for async file writing from JS? I remember using it before, but I can't seem to remember what it is called or find it.

bytesized: OS.File

bytesized: developer.mozilla.org/en-US/docs/Mo…/JavaScript_code_modules/OSFile.jsm

jinx :-)

lol, thank you both. that is it

We're gonna be able to blame mozilla trees burning for global warming soon.