Electrolysis/Meetings/2016-02-04

From MozillaWiki
Jump to: navigation, search


« previous week | index | next week »

mconley

  • M8 bug 1243720 - [e10s] Firefox doesn't respect colors of high contrast mode for web content (Windows)
    • Patch up and waiting on review.
  • P1 bug 1195295 - content-sessionStore.js sends a sync message to the parent in SyncHandler.init
    • This has been driving me up the wall. Posted my findings towards the end - hoping to get mccr8's help.
  • bug 1231422 - Intermittent browser_async_window_flushing.js | We should not have added the window to the closed windows array - Got 1, expected 0
    • Posted a patch, waiting on review.
  • bug 1157404 - [e10s] Possible to end up with two visuallyselected="true" tabs at the same time
    • Patch reviewed, just need to address comments and land.
  • bug 1245713 - Not creating crash dumps for the content process when we should on Linux
    • STR are in that bug.
  • Helping to do UX intern interviewing
  • Reviewing lots of things

bobowen

  • bug 1193861 - We don't get content processes logged on windows - up for review.
  • bug 1219369 - Leak checking does not work in Windows content processes due to being unable to create the bloat log - reviewed, waiting for bug 1193861.
  • bug 1173371 - [e10s] Web page is not shown when launch Firefox from network drive on Windows - landed.
  • bug 1236015 - File menu>Print>Microsoft Print to PDF always results in ERROR - this only seems to happen on Win10 (although I need to check Win8). On Win10 (with 32-bit Firefox) instead of creating a low integrity 64-bit spool helper process the Printer Spooler service creates a medium integrity one, but it still picks up the access token settings from the sandboxed job. This helper then gets used by the main process (and other apps as well) and fails because of the USER_INTERACTIVE settings. I think I just need to get rid of print device access from the content process. Fortunately this doesn't block getting low integrity to Aurora, which I thought it was going to.
  • bug 1245246 - crash in nsPrintEngine::FirePrintingErrorEvent - user had this while testing bug 1236015 for me. Simple null deref - patch landed, will ask for uplift.

gw280

  • bug 1239698 - PScreenManager IPC crash. Spent quite a bit of time looking into this, but didn’t really get anywhere. Ended up asking billm for pointers and he thinks it’s related to the work he’s currently doing, so he took it.
  • bug 1179732 - Tresize. Re-triaged as P2 after the fixes to the addon to bring measurements to almost parity on Windows/OS X. I spent a bit of time trying to work out why the test data shows two trends in the non-e10s case but didn’t get very far. I can’t reproduce it locally.
  • bug 1213432 - currently looking at this, but nothing really to report yet. I have a hunch it might be related to bug 1213429 (d3d9 makes scrolling slower on fb).

felipe

jimm

  • bug 1232181 (M8, Replace plugin windows with static window captures when scrolling) - first window capture approach didn't work for windows clipped by the content view port. Currently experimenting with an old win32 PrintWindow api, looks promising but might have weird side effects, perf issues.
  • bug 1241060 (?, Flash content disappears when scrolling adjacent div) - dom scroll fix landed, apz work around is on inbound.
  • bug 1241060 (M9 (was M8) Flash Player content appears on top of devtools) - culprit turned out to be non-plugin related. There's an odd 4x4 matrix applied to devtool panel, roc asked me to investigate. wip.

gabor

  • bug 1179735 (p1 perf, - tp5o_scroll regression) - Reproduced the issue locally then looked into the test, and tried out various hipotesises (executing the frame script too many times, wrapper issues, CPOW work somewhere, etc) Currently simulating the test on slow page from the test in nightly with a profiler on. It does not look bad at all when I manually scroll in fact it's really smooth, but when simulating the tests there are some noticable small flickering my current theory is that this issue is more about the behaviour of requestAnimationFrame when we're calculating the layerers than about the actual scrolling performance (which is an issue but liekly less critical than let's say twice as bad scrolling with e10s than without)
  • bug 1198191 (p1 perf, - Confirm existing tab-switch telemetry measurement are meaningful) - They are not. In non-10s mode we don't have much working (see follow-up it's already triaged as m8) but I don't think that there is a fair way to compare non-10s vs e10s on telemetry (if the content process is busy tab switch time will be long but in non-e10s browser will hang so you won't be able to start a tab switch). I would prefer to rely on talos tests, and what we have seems like a fair one (tps).
  • bug 1182637 (p1 perf, - e10s is jankier than non-e10s) - Waiting for data to come in... Should we ping someone about this? I would expect that by now we have enough data to see if something is really bad.

mrbkap

  • Lots of test fixes and related work/investigation.
  • Fixed bug 1242472 (m8, tracking protection doesn't block a pixel on cnn.com).
  • I have tons of needinfo, will be working through them over the next week.

bsmedberg (poiru?)

Stability analysis (with addons) 

build ID             non-e10s    e10s-parent   e10s-content
20160127070712         26.397         14.489         37.661

Bug 1210099 is 30% of content crashes, specific to addons.

Next steps: repeat this analysis excluding people with addons, continue to file and prioritize the content process topcrash list: https://crash-stats.mozilla.com/search/?ActiveExperiment=e10s-beta45-withaddons%40experiments.mozilla.org&process_type=content&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

chutten

Responsiveness analysis using preliminary data shows a possible 2% higher rate of janks as measured by BHR in e10s. This number requires further analysis.

Looking at INPUT_EVENT_RESPONSE_MS in bug 1223780 (and, to a lesser extent, the parent-process-only EVENTLOOP_UI_ACTIVITY_MS) shows no obvious trend, so maybe these janks are not user visible.

Checking the distribution of gecko activity as per bug 1182637 shows a dramatic shift to the left as expected after the fix to idle BHR reports .

Note: this is on preliminary data, so it might be skewed by early adopters.

Retrieved from "https://wiki.mozilla.org/index.php?title=Electrolysis/Meetings/2016-02-04&oldid=1115904"