mozilla :: #content

15 Mar 2017
00:59smaugI revealed this bizarre session history bug by fixing another session history bug 4 years ago :/
07:01annevkIt looks like almost nobody monitors Canvas: 2D?
07:01annevkhttps://bugzilla.mozilla.org/show_bug.cgi?id=1347268
07:01firebotBug 1347268 UNCONFIRMED, nobody@mozilla.org Upcoming changes to CanvasContext2D getImageData()
09:38bakudo we already have a separate process for file URLs ?
09:41heycambaku: from https://bugzilla.mozilla.org/show_bug.cgi?id=1147911 it sounds like it
09:41firebotBug 1147911 FIXED, bobowencode@gmail.com Use a separate content process for file:// URLs
10:33farrefor uplifts, do I need to do anything more than setting the approval-mozilla-foo and filling out the comment template?
10:39padenotfarre, usually, no
10:39farrepadenot: good. thanks
12:42farresmaug: ping
12:42smaugfarre: pong
12:42farresmaug: hi! I thought I'd pick your brain about https://treeherder.mozilla.org/#/jobs?repo=try&revision=7482ce0eef18bc6957914c092f738ca1a975032c
12:42smauglooking
12:42farresmaug: it's an intermittent that starts permafailing after Bug 1318720
12:42firebothttps://bugzil.la/1318720 NEW, afarre@mozilla.com Prevent chained requestIdleCallbacks' idle callbacks from being executed during the same idle period
12:43farresmaug: (which is not checked in by the way)
12:45smaugSo we leak worlds
12:45smaugone IdleRequestExecutor object
12:46farresmaug: yep. and one IdleRequestExecutorTimeoutHandler
12:46farresmaug: and the latter is one that we produce a lot more after Bug 1318720
12:47farresmaug: and there is indeed a cycle from IdleRequestExecutor to nsGlobalWindow, but I thought that I handled that
12:48farresmaug: and my gut feeling is that it should reproduce easily in that case. but it doesn't
12:49smaugfarre: do we clear mIdleRequestExecutor when a window is disconnected from a docshell?
12:51smaugyes we do...
12:51farrealso something that I think would show up a lot more (as in as soon as you even look in rIC's direction)
12:52smaugso what all keeps IdleRequestExecutorTimeoutHandler alive?
12:52farreTimeoutManager
12:53smaughttp://searchfox.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#867 should cancel all the IdleRequestExecutorTimeoutHandlers in TimeoutMAnager
12:53smaugperhaps mIdleRequestExecutor->Cancel(); is trying to do that?
12:54farremIdleRequestExecutor->Cancel() breaks the cycle from IdleRequestExecutor to nsGlobalWindow at least
12:54smaugor hmm, is it possible that we do call DisableIdleCallbackRequests(), but afterwards recreate it?
12:54smaugrecreate mIdleRequestExecutor I mean
12:55farreoh.
12:56farresmaug: haven't thought about it from that angle. looking
12:57farresmaug: that can only happen on a call to window.requestIdleCallback and when we resume (as in nsGlobalWindow::Resume)
12:58farreso if either of those can be called when a window is being torn down, then it could happen
13:00smaugfarre: am I reading this wrong...
13:01smaugDetachFromDocShell calls FreeInnerObjects() only on old inner windows, not the current inner window
13:01smaugand it is FreeInnerObjects which calls mTimeoutManager->ClearAllTimeouts();
13:03farreright
13:05farreoh. I think I know what happens
13:06farreno I don't. I only found something strange
13:06smaugfarre: has something changed...
13:07smaugDoes anything call FreeInnerObjects for the current inner window
13:08smaugI guess nsGlobalWindow::DetachFromDocShell() does call it
13:08smaugmust be that way
13:09farrensGlobalWindow::SetNewDocument does it as well
13:11smaugthat doesn't matter during closing down a window
13:13smaughmm, TimeoutManager has mThrottleTrackingTimeoutsTimer which isn't canceled properly, but I guess that isn't used here
13:21smaugfarre: do you leak if you have disconnected window object and call requestIdleCallback on it?
13:22farresmaug: how can that happen?
13:23smaugfarre: you have iframe, take reference to its contentWindow, then remove iframe from document. After this still use contentWindow
13:23farrewindow.open(), get the window, window.close(), call window.rIC?
13:24farresmaug: trying now
13:24smaugfarre: window.close() might not work. iframe is more explicit
13:39farresmaug: so I apparently allow rIC to be called on detached windows
13:54bkellysmaug: the mThrottleTrackingTimeoutsTimer is a thing we are aware of... some disagreement between ehsan and me on how to fix... I duped to the bug we were discussing on
13:54smaugok
13:54smaugfarre: ok, and we schedule rIC and all?
13:55farreyes
13:55* smaug wonders how other browsers handle this
13:55smaugfarre: is the callback called?
13:55smaugin Gecko? what about in Blink?
13:55smaugbut anyhow, does that perhaps cause a leak?
13:56farrethe callback is called. in both gecko and blink
13:56farreand no leak
13:58farrewait. had an error in the test
13:58farredoesn't get called in blink
14:00farreand not in gecko
14:01smaugok, that is correct per spec
14:02smaugfarre: I still wonder if the callback is scheduled internally
14:02smaugjust as a possible way to leak in some case
14:07* bkelly goes out to shovel his driveway again...
14:07* bkelly may not survive.
14:07smaugbkelly: good amount snow?
14:07bkellysmaug: let me convert to metric...
14:07smaugyes please :)
14:08bkellysmaug: 39.624 cm yesterday
14:08bkellysmaug: I'm guessing we got another 15cm over night since I last shoveled (finished at midnight last night)
14:09smaugthat is good. make an igloo?
14:09bkellysmaug: the snow piles along my driveway are like 1.5m high... getting hard to throw the snow over
14:09bkellysmaug: my kids would love that
14:11bkellysmaug: all of this is on top of 120 kph winds last week that knocked out power for 100k people
14:11* bkelly is lucky he did not lose power...
14:12bkellymaybe its closer to 130kph... they measured 81mph gusts at the airport
14:12bkellyanyway.... time to face the music
14:16tbsaundebkelly: heh, Toronto has easily less than 6 inches
14:16tbsaundeoutside of the city maybe more though
14:22* smaug misses good winters
15:31mystorDoes anyone know if there are differences in how xpcshell tests start their content processes compared to firefox proper?
15:46* bkelly survived.
15:47* bkelly yelled at the workmen who parked in the street blocking the snowplow...
15:48bkellytbsaunde: parts of upstate NY got 30+ inches in 24 hours
15:51tbsaundebkelly: yeah, not suprising istr they got like 6 feet in a day once
15:52bkellybit rare fpr ,march, though
15:52bkellyfor
15:53tbsaundeyeah
15:53tbsaundecompletely agree its been a strange winter
18:22* bkelly ran out of class names.
18:22* bkelly has resorted to "ClientThing".
18:22bzfirebot: uuid
18:22firebotdd3f96cb-66fa-46c6-95a0-c7ee58e4962c (/msg firebot cid for CID form)
18:22bzbkelly: ^
18:22bzbkelly: I guess s/-/_/ to make a class name....
18:23bkellybz: that might be hard to type
18:23bzbkelly: I thought all the cool kids used IDEs with nice code completion... ;)
18:23bkellybz: I'm neither cool nor a kid
18:23bkellybz: I'm a curmudgeon who uses vim
18:23bzbkelly: But yes, I think readability would suffer for sure.
18:23bkellyand none of those silly plugins either
18:23bz"cool kids" includes roc, so clearly being a kid is not a prereq....
18:24bkellyI'm a luddite
18:25* bz is with bkelly
18:51* jdm wonders why his Finder is taking 100% CPU
18:54bzjdm: Because It's There.
18:55khueybkelly: meh not as bad as MaybeSomething
18:57* bz should rename MaybeSomething to JustDoItMaybe
18:57bzor something
19:02bzsmaug: Shuld I profile bug 1347525 or are you on top of that (based on the bugs you filed)?
19:02firebothttps://bugzil.la/1347525 NEW, nobody@mozilla.org Setting innerHTML slower than in Chrome/Safari
19:02smaugthere is still more to profile definitely
19:03bzok, I'll take a look too
19:03smaug( I was just taking a break from this session history bug )
19:16jibHi, I need some DOM help.
19:16jibI'm trying to write a mochitest that calls a method from two different origins. I thought I could just write something like:
19:16jibSpecialPowers.wrap(window).location = "mochi.test:777";
19:16jibbut this appears to cause navigation.
19:17jibInstead, is there something I can touch to just change the origin/principal associated with the current JS test?
19:18smaugdoes it need to be the same instance of the method?
19:18smaugand if so, how is that even exposed to multiple origins
19:18smaugif not, just use iframes
19:18jibno, it doesn't need to be the same instance
19:18jibshould I use an iframe?
19:19smaugone iframe loading origin A, one origin B and then communicate with postMessage
19:19jibhow do I give the iframe a different origin while still loading my js?
19:20jibIs there a good mochitest to look at for this?
19:21smaugmochitest can load from many origins
19:21* smaug wonders where the list of predefined origins is
19:24* jib wonders the same
19:27froydnjsmaug: jib: http://dxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt#7
19:28jibfroydn: thanks!
19:30jibfroydnj: thanks!
19:38ajaanyone aware of any online examples combining display:flow-root and oldstyle clearfix ?
19:41bkellyehsan: another thing you could look at for QF is stylesheet memory caching... probably just parser output since actual StyleSheet object depends on the document
19:41bkellyoh, he quit
19:42bkellysigh
20:01smaugbkelly: shouldn't stylesheet mem caching be part of Stylo, if something
20:04bkellysmaug: perhaps... I just know I've seen its an error where other browsers murder us today
20:04bkellysmaug: if you load facebook and then click around we have to keep reloading stylesheets on each navigation
20:04bkellysmaug: other browsers avoid those stylesheet loads
20:04smaugsounds bad
20:04smaugbholley: will stylo help with that?
20:05bkellywe hit http cache, but other browsers don't even have to start a network request, etc
20:05smaugright
20:05bholleysmaug: not that I'm aware of
20:05bkellythere is an ancient bug to implement it somewhere
20:06bkellyehsan_: http://logs.glob.uno/?c=content#c429867
20:06bkellyyou keep going offline
20:14smaugthis "do reload and fragment navigation simultaneously" really does wonders to session history
20:34bkellyI'm actually surprised I didn't get any negative feedback for this blog post: https://blog.wanderview.com/blog/2017/03/13/firefox-52-settimeout-changes/
20:35bkellyafter writing it I was certain some people would say "you're breaking the web!"
20:49bkellyfirefox is back in pwn2own? http://zerodayinitiative.com/Pwn2Own2017Rules.html
20:51bkellyI guess its happening this week
20:52bzyes
20:52bzExpect possible extra work
20:52bkellybz: no firefox scheduled for today... https://www.zerodayinitiative.com/blog/2017/3/15/welcome-to-pwn2own-2017-the-schedule
20:53bkellyour bounty is much lower and we weren't in it last year... may not get much activity?
20:54smaugbkelly: apparently something will happen tomorrow
20:55froydnj$30K is still $30K, and if we are (theoretically) easier to target...
21:09bzbkelly: we know for a fact people had signed up to attack us.
21:09bzbkelly: that said, they did this before we released 52, in case that matters.
21:26froydnjare they required to use 52?
21:26tbsaundebz: I'd think if you were competent you would probably check your exploits work on what will be released for the competition?
21:27tbsaundeas in back when maybe check your exploit against beta
21:28bzfroydnj: they are required to use the most recent release, afaik
21:28bztbsaunde: Yeah, fair.
21:29mccr8froydnj: they use the current release version
16 Mar 2017
No messages
   
Last message: 158 days and 16 hours ago