Electrolysis/Meetings/2014-07-31
From MozillaWiki
< Electrolysis | Meetings
« previous week | index | next week »
Contents
cpeterson
- I blogged about add-on testing: http://cpeterso.com/blog/02014/07/testing-add-on-compatibility-with-multi-process-firefox
- QMO Testday:
- #testday channel
- August 1
- 9:00 AM PT – 4:00 PM PT; busiest from 10:00 AM PT – 2:00 PM PT
- M1 dev-hours burndown: https://people.mozilla.org/~cpeterson/es/e10s-m1-hours.html
- M1 bug count burndown: https://people.mozilla.org/~cpeterson/es/e10s-m1-bugs.html
- M2 dev-hours burndown: https://people.mozilla.org/~cpeterson/es/e10s-m2-hours.html
- M2 bug count burndown: https://people.mozilla.org/~cpeterson/es/e10s-m2-bugs.html
- Add-on bug count burndown: https://people.mozilla.org/~cpeterson/es/e10s-addons-bugs.html
jimm
- m1 update (no changes)
- bug 691601 (e10s support for gFormSubmitObserver) - blocked by review in bug 1015721, r?->dao
- bug 942707 (pdf viewer doesn't work with e10s enabled) - blocked by review, r?->yury
- curious about bug 849746 (webrtc e10s), currently blocks m2, no assignee, sounds complex.
- working on:
- bug 903022 (save-as bug) - patch up for review
- bug 983189 (Text in the find bar gets reset while the page is loading) - wip
- non-e10s work (bug 1044245, bug 1045770)
- tests
- Win mochitest-plain pretty well cleaned up, bug 1041695 remaining.
- Mac mochitest-plain still needs some work.
- Linux mochitest-plain fully enabled on the trees.
- Note, there are still a number of mochitest-plain tests that are disabled in e10s mode.
- A majority of browser-chrome tests are disabled for e10s. A number of these actually reference bugs that have already been fixed. Generally our test coverage here is pretty minimal. Wondering what priority we place on getting bc tests cleaned up and running again.
- http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/general/browser.ini
- http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/newtab/browser.ini
- http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/popupNotifications/browser.ini
- http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/social/browser.ini
alex_tz
- I have finished a first patch for bug 1015466 and will soon move on with this;
- I am currently working on bug 983189 (I asked jimm to let me take care of this);
- I will soon have a Linux machine so that I will be able to investigate what causes some tests to fail with my patch for bug 966395
- I went over the things that felipe suggested for bug 1017914 and I will have a patch soon
bjacob
- Will be on vacation from tomorrow (August 1) until August 10.
- Getting started on printing (bug 927188). Received lots of help from mrbkap and mconley. Realizing that even before we get to worry about serializing anything, the first problem is that printing UI has browser/tab (parent process) and docshell (child process) code very intertwined, and we need to fix that before anything can work.
- Plugin events: closed 586656, filed followup bug 1044182 for cocoa focus, talked with Steven Michaud who has investigated it some already.
- Helped gfx team with a Windows OMTC crasher requiring blacklisting (bug 1018278).
- Non-e10s-related stuff:
- New WS2012 VM test slaves: finished making WebGL tests pass there (bug 978966).
- Made WeakPtr suck less (bug 1044658) and use it to prevent the sec-critical WebGL bug fixed in Firefox 31 from coming back to haunt us (bug 1044668).
mconley
- M1 - Bug 1009628 - Need mozAfterRemotePaint event for remote iframes
- handyman and I have r+! Once the last remaining review issues are resolved, I'll walk handyman through landing.
- M2 - Bug 787975 - Do not cross the client/server boundaries in the JSTerm $0 helper
- Fix landed! \o/
- M2 - Bug 961362 - [e10s] HTML5 video's fullscreen feature zooms video to fill tab, not screen
- Have a patch that works, but a try push reports I'm leaking ~5MB
- Unable to reproduce locally. :/
- khuey suggested I bisect my patch and keep pushing to try, so I'm doing that.
- M2 - Bug 1036433 - can't log into work.com in a remote tab
- I've started to look into this, but it's tough - Work.com uses GWT, which compiles to Javascript, so it's a very unfriendly bit of JS that I'm picking through. Plus, it seems to use some kind of hand-rolled event queue to do things, which isn't helping the complexity.
- I know that the form to submit authentication credentials returns successfully, and I know where in the JS we cause the location to change to complete the login process, so now I'm just narrowing down to see what's breaking down between the two.