WebDriver/RemoteProtocol/Meetings/2019/11/08
From MozillaWiki
< WebDriver | RemoteProtocol | Meetings
Contents
Agenda
- Actions
- Get rid of the MVP bug in favour of the dashboard (whimboo)
- Get in contact with people from the Firefox Headlines newsletter for our addition (whimboo)
- Find out if thereās a way to enable logging of system observer notifications (ato)
- Triaged all the meta bugs for enable/disable methods
- Nearly all are already fixed,except
Fetch
(please have a look out for more meta bugs to close) - How to handle intermittent failures for alpha related bugs? Should those also end-up in puppeteer-alpha?
- Updates from mmucci
- The first Puppeteer example (screenshot.js) is working now (7 more to do)
- Nearly all are already fixed,except
- New remote agent review policy (ato)
- Ditching
r=#remote
, see bug 1593700 - Docs need to be updated
- Ditching
- Update on browser selection in Puppeteer (maja_zf)
- Puppeteer test suite progress (ato)
- Recent test run (with bug 1590467 applied): https://treeherder.mozilla.org/logviewer.html#?job_id=275254586&repo=try
- Security review update (ato)
- about:support (bug 1594351)
- Visual cue, and plans ahead
- Rust port of startup subsystem (bug 1543115) is a dependency requirement for visual cue
Roster
- Present
- mmucci, whimboo, ato, maja_zf, AutomatedTester
- Regrets
Minutes
Actions
- ato
- Not done my action item. Will attempt to do it by next week.
- whimboo
- I got rid of the MVP bug by marking it as incomplete.
- The second action item was about the Firefox newsletter. I got in contact with Mike Conley and he is a bit behind on emails, but will try to get back to me soon.
- I will come back to you when I have more information.
Status of milestone 1
- whimboo
- I have put in some bug statistics tracking progress on a week-by-week basis. It would be useful to keep this in the weekly update going into the future.
- ato
- Yes, it sounds like a good thing to include regularly.
Meta bug triage
- whimboo
- I went through all the
*.enable
and*.disable
meta bugs, and it turns out nearly all of them have been implemented already. - So I did a triage and closed them out after verification, except for the
Fetch
domain, where we donāt implementFetch.enable
orFetch.disable
yet. - So in the future when you work on something and everything related to the meta bug has been fixed, make sure you close it.
- We also now have the milestone and the Firefox tracking bugs, and this will make it easier to keep track of regressions.
- We can see which things have been fixed for which release of Firefox, and so on.
- ato
- I just had a look at the remote protoco dashboard and following these updates it is looking a lot better.
- I notice there are probably some errors with the way these graphs are being created, but itās at least an indication that things are improving.
Prioritising intermittents
- whimboo
- Iām doing most of the work on intermittents currently, and I have a question how these should be related to the alpha release?
- ato
- I think it depends on how important or frequent they are, or how easy they are to fix.
- If thereās an intermittent that negatively impacts the usage experience of the remote agent in a significant way, then we obviously need to prioritise that.
- But if itās something that triggers one in 10,000 times, then maybe not?
- whimboo
- I would count those intermittents marked by OrangeFactor as important regardless, or when the sheriffs come to us with a permafailure.
- ato
- Permafails sounds reasonable, they jump straight to the head of the queue usually.
Update on velocity tracking
- mmucci
- First of all, thank you all very much for tagging bugs properly, marking the P1s and P2s. Itās been working great.
- The backlog is increasing nicely, and this is good.
- Currently there are five bugs in development, there are 15 bugs waiting in the backlog to be selected, we have completed six, and we have one reserved.
- On the dashboard you can the status of each of these, for example if a bug is in review, whether it is landed, &c.
- Right now we should just keep increasing the backlog with the bugs you feel are going to necessary for the alpha.
- My impression, given the pace of development that we are having right now, that it wonāt be a problem to set the forecast on the 22nd.
- whimboo
- When you showed us the tracking dashboard of the other team, there were a couple of different tables?
- Will you add those so we can see how we progress?
- mmucci
- Yes, right now what youāre seeing is the list of bugs with the changes in status.
- None of the tables above are active: they are all blank.
- Plus thereās a tab missing, which is supposed to hold all the performance graphs.
- All that will become active after the meeting on the 22nd.
- ato
- Itās really interesting that youāre saying this, because recently weāve seen an influx of unexpected work coming out of the security review.
Security review
- ato
- David, Thyla [sec team manager], Dan [sec team, and doing the security review for us], and I have been having an email conversation about what remaining things are expected of us.
- Last few days Iāve filed a couple of new bugs based on the suggestions that have come out of that.
- One of follow-ups is to have a new section on about:support that says whether the feature is enabled, is it listening, and where is it listening.
- I submitted patches for that before meeting, and I think itās a reasonable thing to want: if the remote agent is listening and it exposes browser internals, then we need some way of making that discoverable to users.
- The second thing they wanted is a visual UX cue that gets triggered when the remote agent is listening.
- We have a similar feature in Marionette, where the address bar turns orange and it adds a robot icon to it.
- When I implemented that three or four years ago, it was never meant as a security feature. It was meant as a sort of visual indication to the user that a particular browser window that you have open on your screen is being remotely controlled, potentially by a malicious user, and that what happens in that window gets transmitted across a wire protocol that is unencrypted. All this to indicate to the user that you should probably not use that window for your online banking for example.
- It was meant as a hint to the user that thereās something special with this particular browser session.
- The reason itās not a security is that, with both Marionette and the remote agent, you have the ability to evaluate script in the chrome context. And any script evaluated there has the potential of removing this visual hint from the browser UI.
- On the other hand, we already have the feature implemented because we added it for Marionette a number of years ago.
- Another problem I have with the visual cue is that itās kind of annoying and not very pretty. However, I think it would be acceptable if itās only activated when the remote agent is serving a browser-external connection.
- One reason we need to think about this is that we may in the future want to allow browser-internal use of the remote agent.
- For example, imaging a DevTools panel that would let you record-and-replay tests would be quite useful.
- But if the address bar turns orange when you open DevTools, that would not look very good.
- So the way Iām going to resolve this sec-review request is to implement the visual cue only for browser-external connections.
Rust port of startup subsystem
- ato
- I also discovered that triggering the visual cue means that we first have to land the Rust port of the startup subsystem because it changes the API and introduces the necessary system observer notification, which I need in order to implement the visual cue.
- However, I discovered yesterday that Nika who was doing the last piece of the review, has now gone on PTO for three weeks.
- I wanted to ask if you all think itās fine for me to remove her as a blocking reviewer for that change?
- There are a number of other things that are depending on this changeset landing.
- My perception is that it would be fine because the things highlighted in the first pass on the review werenāt super-critical.
- maja_zf
- I think thatās very reasonable.
- whimboo
- Do we have someone else who can look at this code?
- ato
- Iām sure we could find someone. Maybe Nathan?
- But it is quite a substantial changeset, so I just wonder if itās worth including a new reviewer when at least two or three other things that are blocked on it, and we didnāt discover any major design concerns in the first pass of the code.
- whimboo
- The only thing Iām a bit worried about is, if [Nika] is away for three weeks she will presumably have a sizable backlog so I wouldnāt know when a review might be possible to do.
- We might get a review early December, and then we have only two weeks remaining before weāre supposed to be done with the alpha.
- maja_zf
- Perhaps [Nika] has designated a go-to person while sheās away?
- AutomatedTester
- Yes, is there someone else on the team we can approach, and is it worthwhile?
- What is the concern that Nika would fill? Like, why do we need Nika specifically?
- ato
- My suggestion is that we donāt ask a second person because I felt that the first pass didnāt uncover any major concerns.
- But if we need to get someone else to look at thisāif we think that is importantāmy suggestion would be ask Nathan, because heās already been involved in the XPCOM/Rust stuff.
- AutomatedTester
- Iād say go with our review and see how it goes. Nika is already flagged and we could follow up when she comes back.
- Letās not block anything unless there are concerns we are going to meet.
- ato
- I suppose one mitigating factor is that none of this is shipping in Firefox, so until we get the security review done, none of these changes will be exposed to users.
- So if weāre happy with that approach, Iām going to go with our rubber-stamp and land it later today.
- I discovered earlier today it may have caused some leak check regressions, but I will look at this before landing it.
- maja_zf
- If you land it, [Nika] might want to add some comments when she comes back from PTO, but if you remove it from the review queue that wonāt happen. You could set a needinfo just so that it stays on her radar in case she wants to.
- That way it doesnāt look like weāre cutting her off from the conversation.
- ato
- No, I agree. I was going to do something like that anyway. It is likely there will be some need for follow-up.
New review policy
- ato
- I want to propose a new review policy, because I found out last week that it is possible to set up a Phabricator Herald rule that could automatically add the remote-protocol-reviewers group as a blocking reviewer for any change under a designated sub-directory.
- And I first thought of this idea in a different contextā¦ thereās a discussion on dev-platform about how we can make sure incoming review requests from contributors who havenāt set a reviewer donāt get lost.
- There is an issue that unless you set a reviewer, the change request can get lost and the contributor wonāt hear anything back.
- Unlike with Splinter previously, where each component had at least one person in charge of bug triage, thereās no such thing in Phabricator.
- There have been a couple of examples where patches have gone unnoticed and unreviewed, and thatās not a good first contribution experience.
- I think maybe we have had one or two examples of this in geckodriver previously.
- Regardless, it seems to me like a good idea from a usability point of view, because it means we donāt have to remember adding
r=#remote
to the commit messages. - You would just write a patch, submit it to Phabricator, and then Phabricator would figure who is the right reviewer for the change.
- If it works the way I think it will work, it would be an improvement.
- I will let you know when the Herald rule gets added.
- maja_zf
- It still works the same way as setting a group reviewer manually? So if one of us reviews on behalf of the group, that is sufficient? It doesnāt add us individually?
- ato
- So it adds the group.
- You can be added individually as well, but you need a private rule for yourself.
- But I canāt set up global rules myself, so I need someone with [Phabricator] admin access to do it for me.
- I submitted another patch earlier today for the about:support thing, and I noticed there is already a global rule for localisation files. So it seems to be working that way.
- And when someone from that review group reviews it, Lando will then do its usual thing and rewrite the commit message accordingly before [pushing it] to autoland.
- whimboo
- Thereās one thing Iām a bit worried about.
- I sometimes submit patches that are work-in-progress and I donāt want to have a review yet. Thatās why I donāt add
r=#remote
. - Thatās something I donāt want to lose.
- So Iām not sure how others do this, but I want to retain the ability to do this given the recent problems I had with upgrading macOS and lost all my work. So I want to push these patches up to Phabricator instead of just having them on my local disk.
- I donāt want to trigger any review request for this.
- maja_zf
- I think thereās something if you add
wip
to your commit message, the patch will be set as a draft, so itās uploaded but wonāt show up in anyoneās queue. - ato
- But I feel like thatās outlier development processā¦ because eve if you upload a patch and it gets automatically flagged for review you can still go in and edit the revision to remove the reviewer.
- whimboo
- But you have to do it each time you update the patch, I assume?
- ato
- Yes, but I feel thatās maybe a worthwhile tradeoff consider if we donāt have such a rule we risk not paying attention to patches from contributors who forget to set reviewers.
- whimboo
- I only wonder if thereās a way to exclude those patches that maybe have
wip
as a prefix. - maja_zf
- I think that may already be the case. Maybe double-check that and we can circle back and figure out the details.
- whimboo
- Maybe you can add a comment on this bug, Andreas? Perhaps dkl knows if that works.
- ato
- So I donāt think the
wip
thing is something that is built into Phabricator. - I think itās something done by the tool you use to upload the patch.
- maja_zf
- Yeah, maybe itās a moz-phab thing.
- ato
- Yeah. I donāt think Phlay has this, but again, itās not really a use case of mine.
- But I also donāt want us to optimise for a particular workflow that canāt be resolved by two clicks in the UI.
- maja_zf
- Regardless, whatever tool youāre using to upload your patch, there might be an option to set that as a draft.
- Setting a patch as a draft will not cause it to appear in other peopleās queues.
- Maybe look into that, and if that isnāt working for you, then we should discuss again.
- ato
- There are two different states here, right? Thereās āyou upload patch but it doesnāt have reviewersā and āyou upload a patch in a draft stateā.
- whimboo
- Iām using moz-phab and it doesnāt have such an option.
- ato
- But it seems like a reasonable thing to file a feature request about?
- whimboo
- If you have something in a draft state, those bugs will also not be available to any other person.
- It also will not add a link to the bug.
- And that is not what I want.
- I want to have a link to the bug so people can see there was some activity, and they can have access to this patch.
- Then we need to consider the bus factor, when someone has to pick up a patch and continue the work, but if itās a draft you donāt have that, and thatās not how it should be.
- maja_zf
- One second. Regardless, we have a lot of other things to discussā¦ so could we set this particular conversation aside to the end, if we have time and go on with the rest of the agenda for now? Thanks.
- So the next item would be the test suite progress?
Puppeteer test suite progress
- ato
- You will notice from https://treeherder.mozilla.org/logviewer.html#?job_id=275254586&repo=try that there are a lot more tests in the Puppeteer test suite passing now.
- I donāt know if itās specifically because of your patch, but thatās where I looked at the test run log from, or if itās just a result of the last couple of weeksā work.
- maja_zf
- I meant to take a closer look at that, because I noticed a lot more tests are timing out.
- This isnāt in the agenda, but I want to give everyone an update on the browser selection work.
- whimboo
- I had a look and nothing major has really changed. We have two more tests passing.
- The main thing that helped us here was that weāre no longer hanging during the test run, and that was mostly fixed by me with my patch for the
NetworkObserver
. - This is not a change that is related to maja_zfās change.
- ato
- Right, and I think I said as much, that I had only looked at the test run linked from a random recent bug.
- whimboo
- All the stuff you see here I have already filed bugs for.
- And none of this is blocking our alpha release.
- ato
- Right, OK.
- The point I was trying to make is that since the last time Iāat leastālooked at this list, we went from no tests passing and everyting timing out to a lot more passing, in five or six weeks worth of work.
- However if you look at the list of where the remote agent returns
UnknownMethodError
s, that might be another data point which we can use to prioritise what to include in our alpha. - The alpha is not 100% Gutenberg-focussed: it contains things that we think would be possible put into the hands of users before the end-of-year, and so maybe Iāll take an action to summarise these errors from the test log.
- To see if thereās any low-hanging fruit in that list we can easily support.
- maja_zf
- You have a lot on the plate I feel, how about I take that action?
- ato
- Sure.
- Thereās some stuff on this list we already have support for in some capacity in geckodriver or Marionette that we could borrow.
- Thereās a couple of things here that to me seems low-hanging fruit we could quickly support.
- I feel getting an overview of what things we need to implement to move the Puppeteer test suite forward, seems like a good thing to do next.
- maja_zf
- Agreed.
- whimboo
- Iām not so happy we spend time on this.
- We have put Gutenberg and the Puppeteer examples in for the alpha.
- The Puppeteer unit tests cover all the domains, all the methods, and almost all of the events.
- This is way too much, and this is not something we want to do this quarter.
- So I think we should do is get an overview and to file any of those bugs and mark them as mentored.
- We should not work on those: they are not used in Gutenberg, they are not used in Puppeteer examples, and we donāt want to reach 100% Puppeteer support.
- ato
- So I think what you just said is simply not true.
- The things we have included in the alpha is beyond just Gutenberg and the examples.
- whimboo
- Thatās not what I got.
- AutomatedTester
- The thing that we need to be focussing on, is what is doable by end of this year.
- If we think we can get all the domains done by the end of this year, and all the tests passing, then fine.
- I donāt think thatās realistic, but if you think we can, then fine.
- But we can get them documented and Iām happy for us to do that, but I donāt think we need to get everything in now before the end of the year.
- ato
- So I did not say that we are in a position to do everything by the end of the year.
- Thatās not what I said.
- whimboo
- What we have for the end of the year is the alpha.
- Alpha is set for the end of this year.
- ato
- What Iām concerned about is that we work on things that we know users are interested in.
- That we work on stuff we know users are going to be using.
- [?]
- We have prior experience that [informs us] what users are interested in.
- One example I used the other day was [the ability to ignore] TLS certificates.
- My point is that when we have something that either have existing experience for how to do, or better, we have existing code in either Juggler/Marionette that we can re-useāwhich was the case for TLS certsāthen that is a low-hanging thing that requires little investment for us to support.
- On the other hand there are other things in Puppeteer that requires significant work.
- Network events is one example.
- Based on this test log, there seems to be two or three methods that are cropping up a lot that we know is easy to fix.
- Then it might make sense to put these things on the backlog because they would move our test results significantly forward.
- AutomatedTester
- Putting them on the backlog is definitely worthwhile, as long as we only use it as a discussion point.
- We mustnāt get into the habit of āthis is goodā and āpeople might use itā, because we know we will be doing releases at the beginning of next year and itās OK for some thing just to have to wait.
- Letās get it all documented up, and then make a pragmatic choice based on what we document.
- It doesnāt mean we have to do this now, when weāre trying to support he WordPress people to get them using it.
- If we get good feedback on a real-world test suite, thatās awesome.
- On the other hand if theyāre not using it [but] we think it will be high value to people, then letās discuss it and go from there, but only as long as thatās coming from something thatās documented rather than from just throwing everything in.
- If we get everything documented, it creates the next discussion that we need.
- whimboo
- What if we do a little bit of outreach, for people using Puppeteer?
- We have the
DEBUG
environment variable which can print all the used methods and events. - We could have a small script which could parse such a log file and extract what we want to know, then we can get people to run it for us so we know what their test suites are really using.
- I think this could be useful, and we could even make a dashboard for it.
- I could also figure out what [some test suite?] is using, and maybe we can find other people in the community or at other companies who are interested in using Firefox with Puppeteer.
- maja_zf
- Asking them for a log file, we donāt even need to supply a script.
- ato
- Iāve been saying all along that the more data points we have for determining what features are using in real-world tests, the better.
- This is one of the reasons we chose not to focus initially on the Puppeteer test suite, because granted, it does consist of a lot of edge cases.
- That was the right choice [at the time].
- Anyway, it seems like we have a couple of actions here. Maja will go through a Puppeteer test log from a recent run, maybe prioritised by a usage count.
- Based on this test log from the Puppeteer test suite it seems like there are one or two methods would unblock a bunch of other things.
- [talks about how the Puppeteer test suite enables a lot of features before each test]
- maja_zf
- Sounds good.
Browser selection in Puppeteer
- maja_zf
- Thereās a PR open on the Google Puppeteer repo.
- I still have to figure out the Google CLA.
- It enables an environment variable for specifying a product, right now Firefox or Chrome.
- In the tests thereās a hidden variable to configure Juggler, because in the Puppeteer CI they regularly test against the Juggler implementation, and so I wanted to distinguish that from Firefox Nightly.
- And I have to file a bunch of bugs for follow-up work.
- What works now is launching the browser: Puppeteer takes care of profile creation [where it sets] some basic preferences.
- One open question is how to specify āautomation friendlyā preferences?
- I see thereās a RecommendedPrefs.jsm file under remote/, should I put way more stuff under there?
- One of the reasons a lot of tests are timing out is that we have the Firefox āwelcomeā tab it opens up when the browser is started, for example, so the tests canāt even run properly.
- Weāll get more tests passing just by selecting the correct, default preferences.
- Another thing to follow up on is automatically selecting the the default Firefox binary to use.
- Right now Iām relying on the user providing a path to Firefox, but we should either download Firefox or figure out the default.
- Another [method?] in the launcher is connecting to an existing browser instance. We should maybe follow up on this, but it would be lower priority.
- The PR has not been accepted by Google yet, but it is vendored in mozilla-central, and the
./mach puppeteer-test
command uses it already. - There are additional options to better control how you run Puppeteer against Firefox, and you can also use the same command to run the tests against Chrome.
- ato
- [rambles]
- Regarding the CLA, you need to wait for a lawyer to put your name in a Google Spreadsheet.
- Then you may have to close and reopen the PR for the CLA bot to run again.
- maja_zf
- I think maybe you can just tell the bot to run again.
- ato
- Yes that may work, depending on whether [your commits are authored] with your LDAP email address.
- maja_zf
- Do you have any thoughts on where recommended preferences should go?
- ato
- The recurring problem here is that we have some preferences that take effect before the browser is started, and some prefs that can be set at runtime after the browser has started.
- Which is why we have a perfs list in geckodriver that gets written to the profile before Firefox is started and a separate prefs list for stuff we can set at runtime once Marionette has been initialised.
- The mistake we should not repeat with the remote agent is to set too many preferences when the remote agent interface itself gets enabled.
- The reason for that is you want to be able to initialise the remote agent and use it, from say DevTools or for some other browser-internal reason, without [hazardous side-effects].
- Setting preferences at runtime that might interfere with other features would in this case be dangerous.
- A thing I noticed when I did the Rust port of the
nsICommandLineHandler
is thatāfor some reason I canāt explaināit gets run a lot [earlier] in the startup of Firefox than any JavaScript implementation. - So when we had
nsICommandLineHandler
implemented in JavaScript, it ran much later [during startup] than it did when I changed the implementation to be in Rust. - And this is good news for where we can set preferences.
- My suspicion is that we could set more preferences in the startup code once the bootstrapping patch lands, instead of having to split too many preferences between remote agent initialisation and [Puppeteer].
- We should at least avoid setting preferences during
RemoteAgent.listen()
. - Currently we do this and I should perhaps file a bug to move them to Rust too.
- The safest thing to do would be to write the prefs to profile, however.
- If you have some particular problem you need to sort out right now, writing them to the profile first seems like right option.
- Then moving them over to the Rust startup code later.
- maja_zf
- I noticed from the experimental Firefox subfolder in Puppeteer that they have collected a bunch of preferences.
- They have a file that they copy in before they start up the Juggler-enabled Firefox.
- I guess we have a decision to make preference-by-preference about what the responsibilities of Puppeteer vs. [Firefox] should be.
- ato
- You mentioned the browser startup welcome page. I think it would make sense to set this in the profile.
- So that the client that starts Firefox needs to make sure Firefox ends up in a state that it can be used.
- The remote agent is a bit different from Marionette in the sense that it is not purely a component for browser automation.
- There are other use cases where you might want to use the remote agent outside browser automation.
- If you have VSCode and you want to use the remote agent for getting some browser-specific information, you would want to launch Firefox and have it connect to VSCode, [and in this case] you donāt want to set preferences that might interfere with [the browser] because you would want keep interacting with it as a normal user.
- So I think for the things you mentioned, it probably makes a lot of sense for Puppeteer to maintain that list of things that it needs to set in order for Puppeteer to work as expected.
- maja_zf
- Thatās a good way of thinking about it.
- ato
- I suppose if Puppeteer already has a list of preferences it knows it needs to set, thatās good.
- Another source you could use to find out what is relevant would be testing/geckodriver/src/prefs.rs.
- I wouldnāt use geckoinstance.py because it contains stuff thatās related to earlier release channels.
- Well, I suppose this is true also for geckodriver, so I suppose you should look at it with a critical view.
- maja_zf
- Fair enough.
- whimboo
- prefs.rs should contain those preferences that are used before we launch Firefox.
- All the other ones are inside marionette.js.
- maja_zf
- Another next step is removing the experimental directory altogether.
- So keeping the puppeteer-firefox [npm] package around for people to use, but the actual implementation is not under development anymore.
- [explains next steps after PR]
- AutomatedTester
- Just as a slightly tangiental thing, I was having a thought about the puppeteer-firefox stuff: weāll probably take it over at some point to do the browser installation code, because my understanding is that Puppeteer is made up of puppeteer-core and puppeteer-chrome, and that installs the browser, so we might need puppeteer-firefox for installing the browser.
- And the work youāve done in puppeteer-core for browser launching would then just be able to use that stuff.
- ato
- I thought the agreement we had was that we would not be doing anything to the puppeteer-firefox.
- AutomatedTester
- Yes, for now.
- ato
- I mean, not ever. Because the puppeteer-firefox package is Juggler specific, and the whole reason weāre doing this work in the core package is that we want the normal Puppeteer package to be able to select which browser to use so that you donāt need separate npm packages.
- maja_zf
- Yeah, the way Iāve done it, is that depending on which browser you select Puppeteer will download the correct stuff.
- Thereās no puppeteer-chrome.
- ato
- I think the important point here is that we donāt want to break existing users [of Juggler]
- maja_zf
- Yes, that is the argument for keeping the puppeteer-firefox package around, yes.
- AutomatedTester
- Right, OK!
Actions
- Find out if thereās a way to enable logging of system observer notifications (ato)
- Collect list of methods failing with
UnknownMethodError
from a recent Puppeteer test run (maja_zf)
Status of Milestone 1
- Last week: 44 Total; 43 Open (97.73%); 1 Resolved (2.27%); 0 Verified (0%)
- This week: 51 Total; 45 Open (88.24%); 6 Resolved (11.76%); 0 Verified (0%)
Changelog
% git log --date=iso --pretty=format:'%ad%x09%H' -- remote/ | awk '$0 >= "2019-11-01" && $0 <= "2019-11-08"' | awk -F $'\t' '{print $2}' | xargs git show -s --format='%h%x09%an%x09%s' 23ec3d5f2cee Ryan VanderMeulen Bug 1594871 - Disable the racy sub-test. r=whimboo 121f19b7eb9b Henrik Skupin Bug 1587846 - [remote] Add "quality" option to Page.captureScreenshot. r=remote-protocol-reviewers,ato,maja_zf b589179642b0 Henrik Skupin Bug 1587846 - [remote] Add "format" option to Page.captureScreenshot. r=remote-protocol-reviewers,ato d9081e2ef7da Henrik Skupin Bug 1587846 - [remote] Fix payload of return value for Page.captureScreenshot. r=remote-protocol-reviewers,ato ed3629de9e8c Henrik Skupin Bug 1592643 - [remote] Implement Target.activateTarget. r=remote-protocol-reviewers,maja_zf,ato c689ba0e46c8 Henrik Skupin Bug 1591922 - [remote] Page.bringToFront has to wait for activate and focus events. r=remote-protocol-reviewers,ato d06169c5aa69 Henrik Skupin Bug 1592643 - [remote] Methods in Target domain have to raise for invalid "targetId" argument. r=remote-protocol-reviewers,ato c50026801957 Henrik Skupin Bug 1592643 - [remote] Refactor and improve browser chrome tests for Target domain. r=remote-protocol-reviewers,ato 15245002ac1f Andreas Tolfsen bug 1549708: remote: implement Page.reload's ignoreCache argument; r=remote-protocol-reviewers,whimboo a6683fe9a01c Thomas Bug 1591982 - Removed 'timestamp' property from Page.navigatedWithinDocument and Page.frameStoppedLoading r=whimboo,ato 5eef6dba8cc2 Andreas Tolfsen bug 1591927: remote: implement Security.setIgnoreCertificateErrors; r=remote-protocol-reviewers,maja_zf
Work
- Milestones
- Development status of Puppeteer alpha
- Puppeteer alpha dashboard
- Bugzilla queries
- All project work currently in development
- Available MVP work
- Completed MVP work
- Bug overviews
- Gutenberg dependency tree
- Puppeteer examples dependency tree
- Complete Puppeteer dependency tree
- All ze boogs