Episode 1

full
Published on:

28th Feb 2025

Episode 1: Feb 13, 2025 WECG Meeting Recap

Simeon and Oliver chat about what happened in the February 13, 2025 meeting of the WebExtensions Community Group. That may sound boring, but it was actually quite nice and fun, thankyouverymuch.

Chapters

00:47 - Start of main content

01:39 - Announcements: March Meetup

04:22 - Issue 755 | about: matching

13:08 - Issue 756 | Proposal: Exclude Matching

16:11 - Issue 762 | DNR: Add excludedTopFrameDomains (and topFrameDomains)

21:51 - Issue 763 | Proposal: Add excludeTopFrameMatches and excludeTopFrameGlobs

25:58 - PR 760 | Specification for loading extensions in WebDriver Classic

31:54 - Issue 746 | Proposal: Persistent Authentication

34:37 - Wrap up

35:07 - 👀

You can subscribe to the podcast at https://backgroundcontext.com

Transcript
Simeon:

Hello and welcome to Background Context, a show about the Web, Web

2

:

Extensions and the people that build them.

3

:

My name is Simeon and Vincent,

and this is episode one, February

4

:

13th, 2025, WECG meeting recap.

5

:

A couple of days ago, I sat down with

Oliver Dunk, a Google developer relations

6

:

engineer working on Chrome extensions, and

we caught up on the February 13th meeting

7

:

of the WebExtension Community Group.

8

:

I unfortunately wasn't able to attend,

as you'll hear in the episode, browser

9

:

but this was a good opportunity to kind

of catch up on the conversation and how

10

:

things are evolving and, uh, also to just

nerd out a bit on browser extensions.

11

:

I just wanna say a quick thank you to

Google and Mozilla for giving both Oliver

12

:

and me the time to work on this project.

13

:

Hopefully we can keep doing it.

14

:

Simeon: I was supposed to chair the last

web extension community group meeting.

15

:

I woke up five minutes before it ended.

16

:

So, suffice to say I did not attend.

17

:

This seemed like a good opportunity to

try to do a bit of a WECG meeting recap.

18

:

Talk about what we talked about.

19

:

For reference meetings

are not publicly recorded.

20

:

They are public sessions and

we take minutes, but we don't

21

:

actually record the meeting.

22

:

So we don't have like a, don't

have a transcript and we don't

23

:

have like a detailed recording

that people can go catch up on.

24

:

So my hope is that we can sit down

and chat and share some information

25

:

about what browsers and the

community talked about last week.

26

:

Oliver: That sounds good.

27

:

Simeon: So let's start off.

28

:

The first thing on the agenda was

an announcement of the upcoming

29

:

WECG meetup in Berlin in March.

30

:

Uh, I know what I was planning

to say and therefore didn't.

31

:

I'm curious, how did that kickoff go?

32

:

What was shared there?

33

:

Oliver: Yeah, so I think what

you've said is already a lot of

34

:

what we've shared in the meeting.

35

:

It was just a reminder that we're

having an in person meetup in March,

36

:

and then a call out for anybody that's

an active member of the group that

37

:

wants to participate to register their

interest so that we can get an actual

38

:

headcount of who's looking to attend.

39

:

And then I don't think there was much

discussion beyond that, so it was

40

:

just a quick heads up and reminder.

41

:

I'm really looking forward to that.

42

:

I really enjoy those in person meetings.

43

:

Simeon: They are pretty great.

44

:

Yeah...

45

:

I know that I say this every time we

talk about in person meetups, but I

46

:

just really enjoy hanging out with this

group of folks and sitting down and...

47

:

I don't know, it's also like a great

opportunity to nerd out on a niche

48

:

area that you don't get to very often.

49

:

The main thing that I wanted to call

out in, in this -- so I guess I'm

50

:

appending it now -- the wiki page.

51

:

We have...

52

:

the WebExtension Community group has a

on our GitHub, and there is a:

53

:

Berlin F2F Coordination [page] -- F2F

for face to face -- that is the place

54

:

where I'm planning to consolidate all

of the information about logistics

55

:

and schedule and all of that stuff.

56

:

I am in the process right now of kind

of lashing together a rough sketch of

57

:

objectives and goals for the session so

we can start to scaffold out what the

58

:

individual meetings are going to be.

59

:

So I'm going to be, hopefully,

sharing some updates on that shortly.

60

:

Oliver: Great, I didn't know that that

wiki page existed, so that's good to know.

61

:

Simeon: That's also why I added

it to the announcement page.

62

:

So, if you go check out the

meeting minutes for the:

63

:

WECG file meeting notes have

already been updated on GitHub.

64

:

Cool.

65

:

So let's dive into...

66

:

Usually the sessions are divided into

kind of a couple of main sections:

67

:

there's a triage, there's timely issues,

there's checking on an existing issues.

68

:

People before the sessions

will volunteer topics and then

69

:

they'll get added to the agenda.

70

:

By default when any new issues that are

created since our last public meeting will

71

:

get wrapped up into the agenda as well.

72

:

So let's, I guess, start off with it's

a pair of issues: issue 755 and 756.

73

:

The first is "Proposal: about:

matching" and the second is

74

:

"Proposal: exclude matching."

75

:

Oliver: I think one thing that we try

and do often in the meetings is to get a

76

:

clear separation between what the specific

request is and what the use case is,

77

:

because I think the use case is really

helpful to understand and then we'll

78

:

usually start from a point of discussion

focused around the proposal and the issue,

79

:

but sometimes if that proposal doesn't

make sense or doesn't seem likely to be

80

:

something that we'd implement we might

then look at, is there something else

81

:

that we could offer that would solve the

same use case and we'll then go back to

82

:

the developer or whoever opened the issue

and say, "we would be supportive of this

83

:

other thing, is that something that you'd

consider or that would work for you."

84

:

The reason I call that out is because

I think this is a case where we

85

:

had the initial use case and then

we discussed a few different ideas

86

:

around how to solve that use case.

87

:

So, as best as I understand the use

case -- and actually I should say

88

:

here [that] sometimes the author

of the issue is present in the

89

:

meeting, other times they're not.

90

:

So, if they're not in the meeting,

then we do our best to understand

91

:

the use case from what's in the issue

and just sort of using our intuition.

92

:

This is a case where Erosman [eh-ROS-man]

wasn't -- is that how you say their name?

93

:

Simeon: I say "AEROS-men",

but I don't know.

94

:

Oliver: Okay.

95

:

Where Erosman, they weren't present in

the meeting, so we did our best job to

96

:

identify or understand the use case.

97

:

It might not be quite right,

although maybe a piece is missing.

98

:

But the use case was essentially, we

have the context menus API in extensions.

99

:

where you can register

additional context menu items.

100

:

So if you right click on your browser

action, which is the icon your

101

:

extension has in the toolbar or on a

page, you see some specific options.

102

:

And they wanted a way to have those

options appear if you right clicked

103

:

on some sort of web like content.

104

:

So either an HTTP or HTTPS page.

105

:

Or maybe a blank frame, which

doesn't have a HTTP URL, but

106

:

is still in a web like page.

107

:

But they didn't want that context

menu item to appear if you were on

108

:

a file: URL, because the particular

action that they were offering to

109

:

users didn't make sense on a file: URL.

110

:

Simeon: Right.

111

:

Oliver: So these were a couple

of issues that were talking

112

:

about how to approach that.

113

:

Does that sort of make sense

as the initial pitch for the

114

:

problem we're trying to solve.

115

:

Simeon: yeah.

116

:

And I think the first thing that

leaps to mind is Firefox has some

117

:

additional capabilities related to

updating the content of a context

118

:

menu after it has been displayed.

119

:

And I don't think Firefox or, sorry, I

don't think Chrome or Safari support it.

120

:

It's a Firefox only feature.

121

:

But, it gives developers a imperative

way to solve this exact problem

122

:

and to some extent, one of the

tensions that we're looking at here

123

:

is imperative versus declarative.

124

:

That the request is, kind of, implicitly

the ability to better declaratively

125

:

target and the current solution , the

imperative one, is not widely supported.

126

:

So I think it is kind of

a reasonable question.

127

:

Like, we could solve this

with the imperative API.

128

:

Is that the direction that

we want to take the platform?

129

:

Oliver: Yeah, and that's actually

something that Rob brought up.

130

:

I'm not too familiar with how that works,

but he did mention that it would likely

131

:

be a solution to some of these issues.

132

:

I don't know...

133

:

The way I understood it when it

was described was you basically

134

:

get the ability once the menu

is shown to hide certain items.

135

:

Do you know, are you able to do

that before it has its first render?

136

:

Or will the user see a flash of

certain items and then you have

137

:

the opportunity to hide them?

138

:

Simeon: I haven't tested it myself, so

I'm not sure how quick that cycle is.

139

:

I know a hack that people often

use is a mouse over event.

140

:

So sending a message to the

background script on mouse over and

141

:

then In response to the mouse over

event, adjusting the contents of

142

:

the menu before it can be shown.

143

:

And that timing is tight: if the

extension's background context

144

:

isn't alive at the time, it

may take too long to start.

145

:

But, if it is alive, then you have

a fast enough cycle on desktops

146

:

that I've seen to be able to

dynamically update that content.

147

:

Oliver: Okay, so it sounds like even

in Firefox there might be benefit to

148

:

having a declarative way of doing this

so you don't have to start the background

149

:

context if it's non persistent, and

you don't have any of these timing

150

:

issues that you might run into.

151

:

Simeon: Yeah, I think in general

as we talk about and iterate on

152

:

capabilities, one of the things on my

mind is like, how do we start up less?

153

:

Oliver: Yes.

154

:

So, the proposal in this first issue,

755, was to expand the match pattern

155

:

syntax that we have in extensions.

156

:

So extensions have a match pattern

syntax, which supports various patterns

157

:

with wildcards for matching different

contexts -- usually URLs and then

158

:

also a couple of other protocols.

159

:

And the proposal was to add to

the existing patterns we support

160

:

-- about:newtab and about:blank and various

other contexts that you might want to

161

:

match -- because there is already a

documentUrlPatterns filter that you can

162

:

use when you're creating a context menu.

163

:

So you can already say, "I only want

the context menu to show if it matches

164

:

one of these documentUrlPatterns."

165

:

But the problem is, there's no way of

including things like blank frames or

166

:

the New Tab page in that pattern because

they're not supported by the match syntax.

167

:

So as soon as you add that field, they're

never going to show in those contexts.

168

:

So just adding some additional matching

options was the first proposal.

169

:

I think there was some interest

in doing that for contexts that

170

:

we all share across browsers.

171

:

So, for example, I know Timothy,

I believe, was supportive of doing

172

:

that for about:blank because we all

have the concept of empty frames and

173

:

about:blank, and so that's something

that we could potentially all support.

174

:

about:newtab is, I think,

only a Firefox feature.

175

:

I mean, we all have New Tab pages.

176

:

But I don't think any other

browser has about:newtab as a

177

:

special URL for that New Tab page.

178

:

Simeon: Yeah, I think Chrome internally

has it as chrome:newtab and that

179

:

might be aliased to about:newtab.

180

:

I'm not sure.

181

:

Oliver: Yeah, I guess we could check.

182

:

Simeon: Actually.

183

:

Yeah.

184

:

Um, uh.

185

:

Oliver: It looks like it does work.

186

:

Simeon: Yeah.

187

:

Oliver: Yeah.

188

:

So yeah, maybe there's a

justification for supporting it.

189

:

But I think we felt like doing it

that way didn't quite make sense.

190

:

Because even if it's a URL which

is supported behind the scenes,

191

:

it doesn't feel like a very

sort of browser neutral URL.

192

:

Simeon: Hmm.

193

:

Oliver: So then we started talking

about other approaches to this.

194

:

One approach that we were discussing

was Using something similar to

195

:

the match_origin_as_fallback field

that we have for content scripts.

196

:

So content scripts are the scripts that

you inject into the your extension injects

197

:

into a web page, and we have something

called match_origin_as_fallback, which

198

:

is a Boolean flag that you can set.

199

:

And if you set that to true, then as well

as checking against the list of URLs,

200

:

you want your script to run in, we'll

also say if this is an about:blank frame

201

:

or a blob: URL, then we look at what is

the origin that's associated with this.

202

:

So, in the case of a blank frame,

it would just be the parent frame or

203

:

the frame that created that frame.

204

:

In the case of a blob: URL, it would be

whichever origin created that blob: URL.

205

:

And so that provides us a nice way

to match these contexts that we

206

:

can't match with a URL pattern.

207

:

And so we could potentially match using

that in this case for context menus.

208

:

Simeon: Hmm.

209

:

Yeah, I can, that seems

like a, a potential pattern.

210

:

Oliver: And I think that's where we

ended the discussion of this issue.

211

:

So we came up with that possibility

and we wanted to go back and just

212

:

see, would that work for the reporter?

213

:

Is that a good approach for this?

214

:

Issue 756 is very similar.

215

:

The use case I actually think

isn't called out explicitly here,

216

:

but given that they were opened

consecutively by the same author,

217

:

I'm assuming it's a similar use case.

218

:

And this was to have an

exclude matches field.

219

:

And so you could presumably say, if I

don't want to run on file: URLs, then

220

:

I just say exclude, and then in my

array of patterns to exclude I have

221

:

the file: scheme with a wildcard.

222

:

Simeon: Right.

223

:

Oliver: So this is another

approach for doing that.

224

:

It looks like the conclusion we came

to was just clarifying the use cases.

225

:

I think, especially given the discussion

in the previous issue, it would make

226

:

sense to see is it a case of we just

need to close one of these issues

227

:

and then we solve the use case?

228

:

Or is there a case where

we want to do both?

229

:

I also think the second issue was

quite broad or at least not very

230

:

specific about the APIs to touch.

231

:

So the second suggestion is to

add additional matching properties

232

:

to APIs that don't have them.

233

:

Which I think is something we'd all

be supportive of, but we're going

234

:

to need to discuss on a case by

case basis which APIs doesn't make

235

:

sense to change and which properties

make sense for that specific API?

236

:

Simeon: One of the other

complications that leaps to mind with

237

:

exclude matching as the broad category:

match patterns are used in many different

238

:

places and not always the same way.

239

:

Oliver: Yes.

240

:

Simeon: For example,

web_accessible_resources match

241

:

patterns for the contents

that can be injected into...

242

:

I believe that includes paths.

243

:

Is that right?

244

:

Oliver: I believe so.

245

:

Yeah, you're definitely right

that there are certain cases where

246

:

you can and can't have paths.

247

:

I think content scripts,

you can have paths.

248

:

Unless you're in Chrome and you specify

match_origin_as_fallback, in which

249

:

case, we do support paths, but we will

only allow the path to be a wildcard.

250

:

Simeon: This feels like a case

where we could do with some

251

:

distillation of the inconsistencies.

252

:

Oliver: Yes.

253

:

host_permissions is another case

where when you list out the host

254

:

that you'd like access to that

also uses the match pattern syntax.

255

:

And again, in that case,

you have to specify a path,

256

:

but the path is irrelevant.

257

:

So if you don't specify a path, then

we'll show a runtime error saying,

258

:

"we can't load this extension, this

is invalid syntax, there's no path."

259

:

But no matter what you set the path to,

even if you set the path to example.com

260

:

forward slash this very

specific path or no other path.

261

:

We'll treat it as a wild card,

262

:

which yeah, we, we should fix.

263

:

Simeon: That could be a little clearer.

264

:

A'right, let's move on to issue

762: DNR add excludedTopFrameDomains

265

:

and topFrameDomains.

266

:

So that's the excluded version

and the not excluded version of

267

:

this "top frame domains" concept.

268

:

Oliver: And I actually think we should

bundle this one with the next issue.

269

:

So if you want to

introduce that one as well.

270

:

Simeon: Yes, of course.

271

:

Next issue is 763: Proposal:

add excludedTopFrameMatches

272

:

and excludeTopFrameGlobs.

273

:

Oliver: So the use case is

similar between these two issues.

274

:

I think the really important thing to

call out is that these are proposals

275

:

to modify two different APIs.

276

:

So, issue 762 is about the Declarative Net

Request API, which is used for registering

277

:

declarative filtering rules to say,

"if the browser makes a request to this

278

:

URL, I want to block it or redirect it."

279

:

Whereas issue 763 is about

updating the Scripting APIs.

280

:

So, adding new fields that you can

choose, that you can use to control

281

:

whether your extension injects

scripts on a particular page or not.

282

:

Simeon: So what were the goals

of introducing this "excluded

283

:

top frame of domains" concept?

284

:

Oliver: So, this is an interesting

case where if you look at it purely

285

:

in isolation from a technical point

of view, it seems sort of weird.

286

:

Because, generally where you're injecting

is -- or whether you want to inject is a

287

:

decision that you make based on the origin

of the page and not based on the top

288

:

frame, which may or may not be related to

the frame that is currently being loaded.

289

:

They could be completely

different origins, loading

290

:

completely different content.

291

:

But the use case...

292

:

I think the first issue came from

Alexi, who works on Privacy Badger.

293

:

Simeon: Right.

294

:

Oliver: And the second issue came

from polywock, but I think they

295

:

both speak to the same use case.

296

:

Simeon: Mmhmm.

297

:

Oliver: And, so let me let

me try and explain that.

298

:

Let's say that you have a social network,

so you have example-social-network.com,

299

:

and then on that social network page

there's a frame which is a game.

300

:

So this is my-example-game.com.

301

:

And as part of that game, it may

have some social features, it

302

:

might want to use the API of the

social network to pull some data.

303

:

And so even though this is a third

party frame that's completely unrelated

304

:

to the social network, it's still

making requests to the social network.

305

:

And the user might come along

and say, "I'd actually like

306

:

to allow these requests.

307

:

I'd like to allow...

308

:

Anytime that I'm on this social

network, I don't mind if any of

309

:

the frames in this frame tree are

communicating with that social network,

310

:

because that sort of makes sense.

311

:

The...

312

:

For this entire tab, I'm interacting

with that social network, and I'm

313

:

comfortable with making those requests."

314

:

Simeon: Yeah, I...

315

:

Oliver: Does that make sense?

316

:

Simeon: I can see that example being

like, "I am consciously playing this

317

:

game and playing it with friends.

318

:

I want that relationship to be...

319

:

Oliver: Yes.

320

:

... Simeon: available.

321

:

Oliver: And so one of the solutions

that extensions already have today

322

:

is they'll say if I'm on a particular

site and that site is making requests

323

:

which are first party to the origin

of that site, then you can probably

324

:

ignore my Declarative Net Request rules.

325

:

And so, we actually have a

way of doing that already.

326

:

There's a domain type condition in the

Declarative Net Request API, and so

327

:

you can say, "if the domain type is

third party, then apply this rule."

328

:

Which allows you to say,

"if I'm on example.com

329

:

and it's making a request to my

social network, then that's a third

330

:

party request and they don't want it.

331

:

But we don't have a way of saying, "unless

the top frame happens to be this URL."

332

:

And so that's really what these requests

are about, is having some way to say,

333

:

"look at the top frame, and if the top

frame URL is one of these URLs, then I

334

:

don't want to apply these rules," or, "I

don't want to inject these scripts which

335

:

are blocking some other functionality."

336

:

Simeon: Interesting.

337

:

I think...

338

:

This also feels like it dips into the,

the realm of concerns that developers

339

:

have highlighted around the more that

they have to rely on the platform

340

:

providing these edge cases and niche

capabilities, the slower they are to

341

:

evolve and iterate on these concepts.

342

:

'Cause, previously there was no

343

:

to what they could do in terms

of examining content and...

344

:

blocking rules, or was or wasn't

permissible and that kind of thing.

345

:

Oliver: Yeah, and I think this is really

a case where it's really good that we

346

:

have developers using these APIs to tell

us about these use cases, because...

347

:

I think it feels like a -- like I said

at the start -- it feels like a very

348

:

weird concept purely looking at it from

a technical perspective in isolation.

349

:

But when you hear the use case and the

behavior that a user would expect, I think

350

:

it actually seems completely reasonable

and it's something that makes sense.

351

:

And so, this first issue, 762,

we were all supportive of.

352

:

And so we have the supportive Chrome,

Firefox, and Safari labels on that now.

353

:

And it's something that we could

look at implementing in the future.

354

:

Simeon: Very cool.

355

:

Oliver: Then we had issue 763,

which like I said, is the same, but

356

:

this is -- rather than for network

requests specifically -- this is about

357

:

when you choose to inject scripts.

358

:

Simeon: Right.

359

:

Oliver: I think there are

a couple of concerns here.

360

:

One that I had was was that

this is proposing some slightly

361

:

different ways of matching.

362

:

So this is proposing "exclude top frame

matches" and "exclude top frame globs."

363

:

And so the matches is those match

patterns that we spoke about,

364

:

and then globs is an even broader

sort of wildcard matching syntax.

365

:

It's actually quite hard on a technical

level to do that, because generally if

366

:

you have a frame which is cross origin

to the parent frame, then at some

367

:

point along that path you lose the...

368

:

you lose the path.

369

:

Like, you know the origin of the parent

frame you're in, but you don't necessarily

370

:

know the full URL of the frame above you.

371

:

So, figuring out what is the full

path of the top frame is quite tricky.

372

:

And without that full path it

doesn't necessarily make sense

373

:

to support matches or globs.

374

:

So one of the pieces of follow

up that we wanted was to figure

375

:

out is matching against a full

match pattern or a glob needed?

376

:

Or is it enough to simply say,

like, exclude top frame origins or

377

:

domains and match without the path?

378

:

Simeon: Very interesting.

379

:

Looking forward to hearing more about that

use case and what people have in mind.

380

:

This also, kind of, gets into

all of the different patterns

381

:

that are available for matching.

382

:

Depending on the context there's globs

and match patterns and regular expressions

383

:

and possibly other syntaxes as well?

384

:

Oliver: And then the other concern,

or at least, request that Rob from

385

:

Firefox's side had was just to see

sort of more evidence that this was

386

:

something that developers really

needed and that developers were

387

:

already trying to do in other ways.

388

:

So, this is something that you can

implement to some extent already.

389

:

So, you can basically always inject

the content script, and then in

390

:

JavaScript you can actually access

the origin of the top frame, so

391

:

you can have a check, which says...

392

:

Simeon: Mhmm.

393

:

Oliver: ...if

394

:

the origin of the top frame is...

395

:

like matches my origin or is in this

list or whatever, then you can return.

396

:

And so, you have a way to basically

have an early return in your script.

397

:

Which doesn't prevent you from injecting

the script entirely, so that's a nice

398

:

optimization that we could have if we

implemented this as a feature that was

399

:

actually supported in the platform.

400

:

But it does give developers a way

to implement this and show us,

401

:

like, "we're trying to do this.

402

:

If we had a better way,

we would also use that."

403

:

And so Rob was quite keen

to see that sort of thing.

404

:

Simeon: That is always a complicated

issue, especially if a developer is

405

:

consciously trying to do something

so they don't have access...

406

:

It's....

407

:

It's...

408

:

It feels wrong from the developer

point of view to inject it and then

409

:

revoke it because you don't even

want to inject in the first place.

410

:

Oliver: Yes.

411

:

Yeah, it's, at the very least

extra data that has to be sent

412

:

down to that particular page.

413

:

Like, a script that has to be loaded and

parsed that might otherwise not be needed.

414

:

I mean, maybe the whole script

doesn't have to be parsed.

415

:

Browsers are very clever.

416

:

But if you can avoid asking it

to run the script entirely, then

417

:

that's probably better than asking

it to run the script and then it

418

:

immediately returns on the first line.

419

:

Simeon: Unfortunately, I think

it does have to be parsed.

420

:

The entire thing [script] has to be...

421

:

yeah, you need to parse the script

before you can begin execution

422

:

and you can't do that....

423

:

There isn't something at the parsing

stage that would enable you to

424

:

bail, to the best of my knowledge.

425

:

Oliver: Yeah, I just don't know...

426

:

Can you pass...

427

:

Maybe you can pass line by line and, like,

execute the first line and then bail?

428

:

But yeah, definitely outside of my

level of understanding of the JavaScript

429

:

engines that the various browsers have.

430

:

Simeon: Cool.

431

:

So next up, I think we have...

432

:

PR 760: Specification for loading

extensions and WebDriver Classic.

433

:

I believe Kiara has been driving

this work on the Apple team.

434

:

Oliver: Yeah, so I don't think

there's too much to say here.

435

:

We have been working on adding support

for loading extensions to WebDriver

436

:

BiDi, which is the new communication

protocol for tests in browsers.

437

:

We...

438

:

so we have that specification.

439

:

That landed a while back.

440

:

Or at least a few weeks ago.

441

:

Probably longer at this point.

442

:

For Safari, they're planning to

implement this initially in WebDriver

443

:

Classic, which is the previous

version of the communication protocol.

444

:

And so this was just adding some notes on

how they're planning to implement that,

445

:

and sort of making the links between,

this thing that we're implementing in

446

:

WebDriver Classic is based on, this

step of the algorithm in WebDriver BiDi.

447

:

And yeah, we briefly discussed this.

448

:

I've already approved it.

449

:

I think generally everyone's happy.

450

:

So, hopefully this will...

451

:

Oh, it has merged actually.

452

:

I was going to say hopefully this

will be merged soon, but looking

453

:

at the PR it has already merged.

454

:

Simeon: Honestly, I'm really excited

about that work because it's also

455

:

going to enable developers to

do more testing of extensions.

456

:

I...

457

:

You know, this is a mutually beneficial

area where us scratching our own needs

458

:

as browsers and as people working on

trying to make behavior more consistent

459

:

also helps developers better test

and experiment with and verify the

460

:

behavior of their own extensions.

461

:

Oliver: Yeah, for sure.

462

:

I've written quite a few tests

for extensions in the past.

463

:

Actually, I gave a talk in the past

around sort of how to test a browser

464

:

extension and what you can and can't do.

465

:

But previously I think what

we've had has been very limited.

466

:

You've been able to use the

same frameworks that you

467

:

can use to test the web.

468

:

And that's gotten used so far, but

as soon as you want to do something

469

:

which is extension specific -- where

you want to open the pop up or run

470

:

some code in the service worker -- it

starts to get a lot harder.

471

:

So yeah, building out all of this

infrastructure to be able to fully test

472

:

extensions, I think is going to allow

us in the Community Group to write some

473

:

cross browser tests that basically make

sure we have consistent implementations.

474

:

And implementations that are

following the specification that

475

:

we'll hopefully have eventually.

476

:

And then, like you say, for developers

it hopefully means that the platform

477

:

supports all of these things so that

they can then be easier to call in

478

:

Selenium or Puppeteer or whatever

tool you're using to write your tests.

479

:

Simeon: Fingers crossed.

480

:

Looking forward to it.

481

:

So, speaking of WebDriver, our

next issue, 764, is WebDriver:

482

:

install command optional parameters.

483

:

What's going on with this one?

484

:

Oliver: Yeah, so this is basically

just a call to start discussion.

485

:

So, Krzysztov has been...

486

:

Krzysztof has been working on...

487

:

He worked on the initial WebDriver BiDi

specification for how to load extensions.

488

:

So, like I was saying, this

is the the precursor to the PR

489

:

we just discussed from Kiara.

490

:

And so, he's looking at what the

next steps are, and one of the

491

:

things was, "are there various

features that we want to support?"

492

:

So for example, I think Chrome,

Firefox, Safari, Edge -- we all support

493

:

running extensions in incognito.

494

:

And so, do we want to have

a way of controlling that?

495

:

Allowing in...

496

:

Allow an incognito setting

for an extension when we're

497

:

loading an extension in a test?

498

:

And then there are various other settings.

499

:

Firefox has a way to install temporarily.

500

:

There's pinning an

extension to the toolbar.

501

:

There are all these things

that you may want to support.

502

:

And so, this is just starting

some discussion around what

503

:

those things should be.

504

:

What should we support?

505

:

What shouldn't we support?

506

:

And we didn't actually get into the

discussion too much in the meeting,

507

:

rather just calling out that this

issue existed and that we wanted

508

:

everyone to leave their thoughts.

509

:

Simeon: Yeah.

510

:

Krzysztof, from the Ghostery

team has been championing some...

511

:

this WebDriver expansion of capabilities.

512

:

He's been working on the

implementation and doing great work.

513

:

So, my hat's off to him.

514

:

Oliver: Yeah, no, exactly.

515

:

Same from me.

516

:

I think it's been really nice

because we were starting to look

517

:

at working on tests mostly from the

perspective of "how do we build these

518

:

cross browser web platform tests?"

519

:

Simeon: Yeah.

520

:

Oliver: And then he came in looking at

this from the perspective of actually

521

:

how do we support testing more from

a developer perspective wanting to

522

:

write tests for their own extension.

523

:

And it just turns out that we both have

our own reasons for wanting this work.

524

:

I mean, I think we both also

appreciate the other reason.

525

:

It's not like we have these two completely

separate reasons and we have no interest

526

:

in the other reason for doing this work.

527

:

But it's just sort of, it's

all aligned where lots of

528

:

people are excited about this.

529

:

And Krzysztof in particular has been

just going above and beyond with

530

:

opening PRs and then working for a

lot of feedback to get those landed.

531

:

I know as soon as you write anything

that has sort of specification text,

532

:

you get a lot of feedback and so I

really appreciate him working through

533

:

all of that and getting to the point

where we actually have something

534

:

which has landed now and hopefully

browsers will be implementing soon.

535

:

Simeon: That's the old adage: the

easiest way to find the correct

536

:

answer is to share the wrong one.

537

:

Oliver: Yes

538

:

Simeon: and last up, issue 746:

Proposal: Persistent Authentication.

539

:

I think this was a late add.

540

:

Did anything end up

happening with this issue?

541

:

Oliver: I think this was on the agenda

from the start of the meeting, but

542

:

unfortunately we didn't get to it.

543

:

So we didn't have any discussion.

544

:

Simeon: Uh, It wasn't on

the agenda that I prepared.

545

:

Oliver: Okay, maybe not then.

546

:

Simeon: No, no, no.

547

:

I, I, I think it was like it was suggested

in the time shortly before the meeting.

548

:

Oliver: Okay, yeah.

549

:

Simeon: I think it was from the start

of the meeting to the end on it.

550

:

It just...

551

:

Oliver: One thing I do really appreciate

is we have been getting a lot better

552

:

over time at having more of the

agenda prepared before the meeting.

553

:

Simeon: Yeah.

554

:

Oliver: So this week actually was a

really nice case where I felt like more

555

:

than ever before I was able to take a

look at the issues before the meeting.

556

:

I had some conversations on the

Chrome side with various members

557

:

of the team to see is there

something we'd be interested in?

558

:

Do we have any thoughts that we

should share in the meeting so we

559

:

can get some immediate feedback.

560

:

And I think that just,

it helps us get a...

561

:

It helps us sort of give our support or

any further questions on the issue as soon

562

:

as possible, which keeps things moving.

563

:

Simeon: Yeah, one of the other things

that we do to try to help organize

564

:

and collect this information is...

565

:

we create a agenda issue.

566

:

In an issue on our GitHub repo with

the "agenda" tag, and there should

567

:

only be one of those open at a time.

568

:

That will be the next meeting's agenda.

569

:

And people can make suggestions

about what they'd like to see added.

570

:

I want to get better about, multiple

times over the the lead up to a

571

:

meeting, updating the placeholder agenda

with content as people propose it.

572

:

As it evolves.

573

:

Usually I try to do it at

minimum 12 hours before.

574

:

But I, I would like to

extend that further out.

575

:

Oliver: But I think even the way it's been

working up to now, I think that works.

576

:

It's easy enough to skim through

the comments on the agenda issue and

577

:

see what's going to be discussed.

578

:

Of course, keeping the summary at the

top open is, or up to date is also

579

:

nice, because sometimes there might be

some discussion in the thread, and then

580

:

you don't have to read through that

to see what the actual end result is.

581

:

But I think it's workable.

582

:

We haven't had too much

discussion up to now.

583

:

Simeon: Badum

584

:

Oliver: ba!

585

:

Simeon: That's the audio sting you get

to say we're done with the episode.

586

:

So that's it.

587

:

It's a pleasure talking with Oliver.

588

:

Hopefully gonna do

another one of these soon.

589

:

We just had the February 27th meeting

of the Web Extension Community Group, so

590

:

there should be another episode coming

out in the not too distant future.

591

:

Don't know when.

592

:

Turns out audio editing is hard.

593

:

We'll figure it out.

594

:

The show is online at

backgroundcontext.com.

595

:

Thanks for listening and

see you on the internet.

596

:

As a kind of final bit

you get me making noises.

597

:

598

:

uugggh

599

:

hrm

600

:

601

:

head_desk.mov

602

:

603

:

604

:

605

:

I don't know what that was.

606

:

Well, you're listening to it.

607

:

So that's the end.

608

:

Bye.

All Episodes Previous Episode

Listen for free

Show artwork for Background Context

About the Podcast

Background Context
A show about the Web, WebExtensions, and the people that build them.
A show about the Web, WebExtensions, and the people that build them.

About your host

Profile picture for Simeon Vincent

Simeon Vincent

Simeon (he/him) is a bald guy with ADHD who thinks browser extensions are pretty cool, actually. He is a co-chair of the WebExtensions Community Group (WECG), works on WebExtensions at Mozilla as a Developer Relations Engineer, and is a Google Developer Expert for WebExtensions.