Electrolysis/Meetings/2016-02-18: Difference between revisions
< Electrolysis | Meetings
Jump to navigation
Jump to search
(gabor's progress) |
(gabor's progress edit) |
||
| Line 34: | Line 34: | ||
== gabor == | == 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 | * {{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. | ||
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|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) | * {{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) | ||
Revision as of 17:01, 18 February 2016
« previous week | index | next week »
mconley
- M9 bug 1246115 - "This isn't a web forgery…" never appear for webpages detected as forgery
- Fixed, waiting on uplift approval.
- M9 bug 1246291 - [e10s] about:preferences#advanced - "Warn me when websites try to redirect or reload the page" doesn't allow redirects
- Found a way forward. Patches up for review.
- M9 bug 1248599 - [e10s] The user is not automatically signed into the Firefox account after resetting the password
- The problem is that about:accounts is run in the parent process, and the localStorage thing they're doing to detect when the session has been opened doesn't work across processes.
- Looking at alternatives now - specifically, looking at seeing how hard it would be to make about:accounts run remotely (I don't think it does much privileged stuff)
- Perf P1 bug 1195295 - content-sessionStore.js sends a sync message to the parent in SyncHandler.init
- This has turned into a pretty epic leak hunt that has nothing really to do with my patch (I think my patch just exposed it more).
- Apparently, nsFrameLoader leaks sometimes which keeps nsInProcessTabChildGlobal alive. See bug 1249226.
- Bug 1247100 - 5.08% sessionrestore (linux64) regression on push cb036027df84 (Mon Feb 8 2016)
- 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 (e10s stability)
- Crash analyses:
- Filed bug 1249209 to track top crashes in beta45-withoutaddons experiment
- bug 1003004 responsible for >20% of content process crashes in experiment
chutten
- Learning how to use the longitudinal dataset
- Reran the jank threshold analysis on beta45ex2 data: E10s responsiveness measures still looking good.
jimm
- todo
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)