105
edits
(jimm) |
(→chutten: link to analysis) |
||
(8 intermediate revisions by 5 users not shown) | |||
Line 20: | Line 20: | ||
** I've found a potential solution to this, and the pattern I've used (moving things out of frame scripts into common JSM's) might help us gain more ground all around on session restore times. | ** I've found a potential solution to this, and the pattern I've used (moving things out of frame scripts into common JSM's) might help us gain more ground all around on session restore times. | ||
== poiru | == poiru == | ||
* [https://github.com/vitillo/e10s_analyses/blob/master/beta45-withoutaddons/e10s_crash_rate.ipynb e10s crash rate] for beta45-withoutaddons experiment (considers control-no-addons/experiment-no-addons branches) | |||
build ID non-e10s e10s-parent e10s-content | |||
20160211221018 24.325 12.396 19.977 | |||
* Filed {{bug|1249209}} to track top crashes in beta45-withoutaddons experiment | * Filed {{bug|1249209}} to track top crashes in beta45-withoutaddons experiment | ||
** {{bug|1003004}} responsible for >20% of content process crashes in experiment | ** {{bug|1003004}} responsible for >20% of content process crashes in experiment | ||
Line 28: | Line 31: | ||
== chutten == | == chutten == | ||
* Learning how to use the longitudinal dataset | * Learning how to use the longitudinal dataset | ||
* Reran the jank threshold analysis on beta45ex2 data: E10s responsiveness measures still looking good. | * Reran the [https://gist.github.com/chutten/3129baf8d5e0f10ef54a|jank threshold analysis] on beta45ex2 data: E10s responsiveness measures still looking good. | ||
== jimm == | == jimm == | ||
* | * {{bug|1229429}} (+, Rapid tab switch displays plugin window in wrong tab) - fixed | ||
* {{bug|1232181}} (M8, plugin window captures) - tests builds up for Jeff, some issues with win10 and sandboxing. Should have a new rev up today. Also working on GTK support. | |||
== gabor == | |||
* {{bug|1179735}} (p1 perf, - tp5o_scroll regression) - Did some profiling locally on the original tests after applying Mike's patches. Had a bunch of theories but neither of them turned out to be true (vsync on compositor side, slower js in e10s, something holding up the ticks, etc.). At this point it just seems that we paint slower for some reason... but nothing obvious can be spotted on the profiler data. Unfortunately the test does seem quite valid and the perf regression is quite significant. | |||
* {{bug|1232638}} - (p1 perf, -IPDL::PCookieService::RecvGetCookieString causing janks) - As it turns out it should be possible to get rid of the cookie getters in the child for the http requests. I could not find this to be a perf problem for page loads, so I'm still unsure about its priority. | |||
* {{bug|1248130}} - (m9, Crashing user in wrong e10s experiment branch) - Tried some edge cases to reproduce it. I found some cases where the flag is not correct temporarily (after disabling an addon the flag is updated but the status of the addon is only updated after restart, same for enabling) | |||
== gw280 == | |||
* {{bug|1213432}} - d3d11 warp slower than unaccelerated. Spent quite a bit of time looking into getting Concurrency Visualiser working so that we can profile it. Was working through the profiles with jrmuizel but he's on PTO this week, so put this on hold until he's back next week so we can continue trying to work out what's going on. | |||
* {{bug|1114647}} - rename content process. decided to do something a little more involved. going to rename the content process for everyone to "firefox-webcontent", and then we will duplicate the .exe for firefox-plugin-container.exe. Should have a patch up by the end of day. | |||
== mrbkap == | |||
* {{bug|1113196}} - Passing wrong context node for top-level document loads in the loadinfo - Attached a patch (green on try) that fixes the bug for now, waiting on Tanvi's patch to fix it cleanly. | |||
* {{bug|1095484}} - Extension protocol handlers aren't registered in child processes - Attached a patch and waiting for feedback. | |||
* {{bug|1183915}} - Drag & drop of images *from* Firefox *to* specific other applications doesn't work - Investigated yesterday. Should have a patch today. | |||
* Still working on tests. |
edits