00:19
MikeSmith
googles The Brand New Testament
00:20
MikeSmith
sees Catherine Deneuve so that's a definite plus
05:50
<Krinkle>
Hm.. is it standards-specified that there will be own properties on localStorage for all stores keys?
05:50
<Krinkle>
I'm trying to find a good arguments for why Object.keys(localStorage) is bad.
05:51
<Krinkle>
I can't find it explicitly on https://html.spec.whatwg.org/multipage/webstorage.html#storage-2 except for the sentence "The supported property names on a Storage object are the keys of each key/value pair currently present in the list associated with the object" - I'm not sure what that sentence even means.
06:08
<annevk>
Krinkle: that's IDL language for saying it has own properties
06:09
<annevk>
Krinkle: iirc
06:14
<Krinkle>
annevk: thx.
06:14
<Krinkle>
Quite fascinating behaviour
06:14
<Krinkle>
localStorage.setItem('setItem', new Date()); Object.keys(localStorage); // [ setItem ] and yet localStorage.setItem; // [native]
06:14
<Krinkle>
so its there but the inherited one does overlap
06:15
<Krinkle>
Is that standards, too :D ?
06:17
<annevk>
MikeSmith: https://twitter.com/annevk/status/646569118485901312
06:18
MikeSmith
looks
06:18
<MikeSmith>
yeah I figured
06:18
<MikeSmith>
cool that it crashes the entire browser though
06:18
<annevk>
Krinkle: yeah, due to lack of OverrideBuiltins which we cannot add at this point iirc
06:19
<annevk>
Krinkle: [OverrideBuiltins]
06:19
<MikeSmith>
hat tip to amirrajan for finding that bug
06:26
<Krinkle>
annevk: Ah, I see. Looks like github/whatg has no mention of it, but there are a few matches in w3c https://github.com/search?q=OverrideBuiltins+%40w3c&type=Code
06:27
<Krinkle>
https://w3c.github.io/html-reference/form.html#form-interface
06:28
<Krinkle>
But yeah, that's an undefined IDL ref.
06:33
<Krinkle>
annevk: Found it. https://github.com/heycam/webidl/blob/HEAD/lc2.txt#L164
06:44
<annevk>
Krinkle: https://heycam.github.io/webidl/ is the IDL specification
06:45
<Krinkle>
Yeah
06:45
<Krinkle>
So OverrideBuiltins is part of that standard, but not allowed for partial interfaces yet.
06:45
<Krinkle>
not sure if that's relevant though
06:45
<annevk>
Krinkle: and the HTML Standard uses OverrideBuiltins, e.g., as part of DOMStringMap
06:45
<Krinkle>
Ah, it's already being used. cool
06:46
<annevk>
Krinkle: I don't think we can change localStorage though
06:47
<Krinkle>
github search didn't pick up on that, presumably because whatwg/html:/source is too large or extensionless
06:47
<annevk>
Krinkle: also not sure whether we want to, localStorage should not be used
06:47
<Krinkle>
I've created https://github.com/whatwg/html/issues/183 for now
06:47
<Krinkle>
I'm entirely satisfied if it's a no, but would like a paper trail for it.
06:51
<Krinkle>
annevk: Well, that's easy to say. There doesn't seem to be a good alternative at the moment. At least we're using it behind a few abstraction layers, but in that layer I noticed some code using Object.keys() and it looked quite odd. Since people usually use a .length for-loop calling .key()
07:10
<annevk>
Krinkle: yeah, I guess it'll be hard to move away from existing usage
07:10
<annevk>
Krinkle: alternative is IDB
07:11
<Krinkle>
Yeah, but that requires a million lines of code to set and get a single key last I tried. Having said that, I've not looked at it properly. we have an open task to migrate to that.
07:11
<Krinkle>
But less support-ish, but we could always fallback to localStorage. There's a few libraries that do that.
07:11
<Krinkle>
Though the async-ness means we can't easily migrate existing code.
07:12
<Krinkle>
I wish localStorage was async from the get-go, would've encouraged better code.
07:17
<annevk>
Now I'm conflicted: https://github.com/whatwg/fetch/issues/97#issuecomment-142449720
07:18
<annevk>
Krinkle: might be a couple of order of magnitudes less
07:18
<annevk>
Krinkle: yeah, the synchronous IO bit is the main problem with localStorage
07:38
<zcorpan>
https://lists.w3.org/Archives/Public/public-texttracks/2015Sep/0013.html
08:17
<annevk>
zcorpan: interesting
08:17
<annevk>
zcorpan: feel free to create whatwg/webvtt
08:18
<annevk>
zcorpan: and then ping Hixie about adding the domain to my account
08:19
<annevk>
https://twitter.com/zcorpan/status/646594862616309760 :-)
08:29
<annevk>
zcorpan: perhaps ask philipj if he can manage to keep the webvtt version history somehow
08:34
<philipj>
annevk, zcorpan, just make a fork of the existing repo I guess?
08:34
<annevk>
philipj: oh, heh, I thought there was still only the CVS one
08:35
<philipj>
annevk: no, it's not that bad, the CVS is just the mechanism for publishing to http://dev.w3.org/html5/webvtt/
08:35
<philipj>
s/the//
08:38
<MikeSmith>
gsnedders: fyi http://stackoverflow.com/questions/32731479/lxml-html5parser-ignores-namespacehtmlelements-false-option
08:39
<MikeSmith>
gsnedders: I got lazy about trying to troubleshoot it myself. Maybe I can get somebody else to do it for me
08:40
<MikeSmith>
philipj: I'd suggest please that the group quit publishing that http://dev.w3.org/html5/webvtt/ URL. We can just set up a redirect from there to some saner place.
08:42
<MikeSmith>
I hope to see the day when we're not longer actually versioning anything at http://dev.w3.org but instead it exists just for redirects of old URLs to keep them from breaking
08:42
<philipj>
MikeSmith: zcorpan is now the editor, but I'd be delighted to see the spec published on webvtt.spec.whatwg.org (or w3c.github.io/webvtt) with a redirect
08:42
<MikeSmith>
yeah
08:42
<MikeSmith>
let's do that
08:42
<MikeSmith>
doesn't sound like anybody in the group objects to it
08:43
<annevk>
philipj: perhaps it's better than to just move the repo?
08:43
<philipj>
annevk: not sure if it's possible to move a repo between organizations, but if it is, sure
08:44
<annevk>
I think so, though haven't done it before
08:44
<zcorpan>
is it considered moved if one does a fork and then remove the original?
08:44
<philipj>
zcorpan: no, I can't imagine that would set up the redirects that a move results in
08:44
<zcorpan>
ah ok
08:45
<zcorpan>
MikeSmith: what is the "best" way to publish stuff on TR/ these days?
08:45
<MikeSmith>
autopublish thing
08:45
<MikeSmith>
called "Echidna"
08:46
<annevk>
mkwst: I'm not entirely comfortable leaving the document bit as an open issue for HTTPS state
08:46
<zcorpan>
MikeSmith: ok
08:46
<MikeSmith>
zcorpan: I am happy to help anybody/any group get set up to do that
08:46
<MikeSmith>
once you have it set up, you can push to TR/ space at will
08:46
<mkwst>
annevk: Ok. Do you have suggestions? :)
08:46
<philipj>
zcorpan: whenever we asked to get that autopublished for /TR/webvtt1 we got pushback because the TTWG wants to OK every revision
08:47
<MikeSmith>
philipj: oh geez
08:47
<philipj>
so I just opted to never take the initiative to update /TR/webvtt1 at all
08:47
<zcorpan>
philipj: :-(
08:47
<MikeSmith>
I think they just need to be politely told, sorry, no
08:47
<annevk>
mkwst: it seems it is defined when a document is created as a result of navigation
08:48
<philipj>
MikeSmith: do you know how to be polite?
08:48
<philipj>
zcorpan: the one thing that makes it less terrible is the quite prominent warning/redirect at the bottom of http://www.w3.org/TR/webvtt1/
08:48
<philipj>
also, that not much has changed normatively since the last update
08:49
<MikeSmith>
philipj: well, scratch the politeness plan actuallyーI can instead bring it to Philippe's attention and he won't bother to be polite to them
08:50
<philipj>
MikeSmith: I'm pretty sure that he was on CC on these discussions
08:50
<MikeSmith>
well the autopublishing thing is Philippe's project, and he's a very strong advocate for groups to use it
08:50
<philipj>
But my memory is now unclear and the discussions not in public, so better to approach it as a new question rather than "Y U NO AUTOPUBLISH?!"
08:50
<MikeSmith>
and one group cannot block another group from doing whatever it wants
08:51
<philipj>
MikeSmith: /TR/webvtt1 is published "by" the TTWG
08:51
<MikeSmith>
they can make a formal objection to some decision but I am pretty sure I already know the Director would not be sympathetic to an FO around this
08:51
<MikeSmith>
ah
08:51
<MikeSmith>
ok
08:52
<philipj>
there is no other WG involved with WebVTT, there's just the text tracks CG
08:52
<MikeSmith>
oh christ this "joint deliverable" stuff is without an exceptions always a bad idea
08:53
<MikeSmith>
philipj: OK
08:53
<annevk>
mkwst: however, a document as result of navigation can be either the result of a request or a response (and sometimes I think a Document object gets reused)
08:54
<MikeSmith>
hmm well Dave Singer is the co-chair of that WG and he is always flexible and helpful in my experience
08:54
<MikeSmith>
so maybe we can just ask Dave to please sort it out so that it can be autopublished
08:55
<philipj>
MikeSmith: sure, it's worth another try, previous discussions were never initiated by me or Silvia
08:55
<roc>
annevk: why haven't we added a simple promise-based wrapper API to IndexedDB which covers the localStorage usecases in a convenient way?
08:55
<zcorpan>
MikeSmith: do you have the right Powers to move the repo? it seems i don't have a settings button
08:56
<MikeSmith>
zcorpan: hang on
08:56
<zcorpan>
https://help.github.com/articles/transferring-a-repository/
08:56
<annevk>
roc: transactions and promises were hard to reconcile iirc
08:56
<MikeSmith>
zcorpan: try now
08:57
<roc>
localStorage doesn't even have transactions so I don't see why that would block things
08:57
<zcorpan>
MikeSmith: settings button appeared
08:57
<MikeSmith>
super
08:57
<annevk>
roc: https://gist.github.com/inexorabletash/c8069c042b734519680c has some ideas
08:58
<annevk>
roc: IDB has transactions so you'd break that invariant and it would no longer be a "wrapper"
08:58
<roc>
you just put every operation in its own transaction
08:59
<zcorpan>
hmm. i suppose i don't have admin rights in whatwg. annevk?
08:59
<annevk>
zcorpan: you do, you're in Owners
09:00
<zcorpan>
oh, i wrote "w3c" instead of "webvtt" in the "write the repo name to confirm" field
09:00
<roc>
I guess the argument in https://groups.google.com/forum/#!msg/mozilla.dev.gaia/g5_eOE7YHWw/s8dH40HC8lsJ is that you actually need transactions and people who use localStorage without them are exchanging reliability for convenience.
09:02
<annevk>
roc: technically without the storage mutex there's a lot of potential for weird behavior with localStorage and cookies, but I haven't seen folks run into it in practice
09:02
<roc>
yeah
09:05
<annevk>
roc: but I'm not sure why we still haven't added a new simple API
09:06
<annevk>
roc: I think maybe in part folks are hesitant to add yet another storage API and in part some folks have been pushing for figuring out the primitives underlying IDB and exposing those first...
09:06
<zcorpan>
annevk: ok i've moved the repo and created a Team for it
09:06
<annevk>
roc: which I think https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191 is about
09:07
<annevk>
zcorpan: okay, so once the domain name is setup I can make sure publishing happens automatically
09:08
<annevk>
zcorpan: and then I guess you might want to configure a Twitter account for it and such
09:08
<zcorpan>
Hixie: can you please create webvtt.spec.whatwg.org and add it to annevk's account?
09:37
<mkwst>
annevk: Sorry, had to run out.
09:37
<mkwst>
annevk: I'm trying to trace the navigation pieces to see where we have a response. It looks like we will end up in the "initialize" mechanism regardless of how we git the bits we're parsing.
09:40
<mkwst>
Step 15 of https://html.spec.whatwg.org/#navigating-across-documents fetches the data, then step 24 farms it out to one of HTML or XML or whatever, each of which ends up calling "initialize the Document object".
09:41
<annevk>
mkwst: yeah, that matches my understanding
09:41
<annevk>
mkwst: there's something with history traversal where an existing Document object can get reused, but in that case it should already have the HTTPS state set to something
09:41
<mkwst>
annevk: Right. I think we only care about this when we create a new Document object.
09:42
<annevk>
mkwst: it might be better to associate this with the Window object though, since for many Document objects this state does not make sense
09:43
<annevk>
mkwst: e.g., why should new Document() have an HTTPS state?
09:43
<mkwst>
sure. that would match the state on the worker.
09:43
<mkwst>
that makes sense.
09:43
<annevk>
mkwst: the only tricky thing with that seems to be document.open(), which can replace the Window object while keeping the Document object
09:44
<annevk>
mkwst: I guess you'd have to copy the state across there
09:44
<mkwst>
annevk: In that case, yeah, we'd copy the state over.
09:50
<JakeA>
Domenic: any docs on the tc39 discussion on cancellable promises?
09:58
<smaug____>
annevk: then that part of the spec is totally unreadable
09:59
<annevk>
smaug____: I'm not going to argue it's great
10:00
<annevk>
smaug____: but I'm not sure I would have done a better job given the kind of insane model Hixie has reverse engineered
10:01
<smaug____>
hmm, "spin the event loop" looks buggy
10:01
<smaug____>
"Queue a task to continue running these steps" o_O ?
10:03
<annevk>
smaug____: perhaps we could refactor that so that spin the event loop instead takes a "task" to run
10:03
<annevk>
smaug____: or a set of steps
10:03
<annevk>
smaug____: that might make it a bit more readable to programmers
10:05
<smaug____>
so random other tasks might run between 8 and 10
10:06
<smaug____>
hmm
10:06
<smaug____>
so the algorithm wants to effectively clear task queue from anything there was when "spin the event loop" was called
10:06
<smaug____>
and more
10:07
<smaug____>
anything the scripts added during that microtask checkpoint
10:11
<annevk>
"spin the event loop" basically seems like "wait while running the event loop until X is true and then when X is true queue a task to do my thing"
10:11
<annevk>
However, only X is an explicit argument, "my thing" is a tad more hand wavy
10:15
smaug____
is pretty sure this isn't anything what browsers do
10:15
<smaug____>
the sync even loop spinning there
10:17
<annevk>
smaug____: what do we do instead?
10:18
<annevk>
smaug____: or more interesting, what's observably different?
10:21
<smaug____>
"wait for the goal and continue" is probably closer. And in case of defer scripts, not sure what wk/blink do, but run defer scripts when document and defer scripts have been loaded - right before DOMContentLoaded
10:21
<smaug____>
spinning the event loop between running defer scripts is definitely observable
10:23
<annevk>
MikeSmith: happy b-day! 🎉
10:24
<annevk>
smaug____: okay, so you mean that Firefox waits until all <script defer> have been loaded
10:25
<annevk>
smaug____: what if a <script defer> inserts another <script defer>? I guess that doesn't work the same perhaps...
10:25
<annevk>
ah yeah, wouldn't be parser inserted
10:28
<MikeSmith>
annevk: thanks ✌️
10:34
<smaug____>
annevk: so Gecko has a queue for defer scripts. non-empty queue block DOMContentLoaded to fire
10:34
<smaug____>
but when we process defer scripts, we do it in a loop until there are no other loaded scripts
10:34
<smaug____>
and then wait for loading if there is something to load
10:34
<smaug____>
I guess that could change so that each defer script uses it own task
10:35
<smaug____>
that would be perhaps the sanest also from spec point of view
10:36
<annevk>
that's what the spec does, it just doesn't wait for all of them to load first
10:36
<annevk>
just waits for the parser to stop
10:38
<smaug____>
hmm, true
10:38
<smaug____>
the sync event loop spinning just harms readability a bit
10:38
<smaug____>
ok, let me write a gecko patch
10:39
<smaug____>
need to also change microtask handling
10:39
smaug____
wonders when html spec got different microtask handling from the original mt
10:40
<smaug____>
I guess it needs it because of using sync event loop spinning so often
10:46
<annevk>
smaug____: maybe when it started to be used for more than just mutation observers?
10:46
<annevk>
smaug____: I'm happy to make the event loop spinning more readable
10:47
<annevk>
smaug____: e.g. by passing in the steps to be run when the goal is met, rather than doing that in the somewhat weird way it is done now
10:47
<smaug____>
well, at least that mysterious ''until X" param could be improved
10:48
<smaug____>
it certainly doesn't sound like a param to the algorithm
10:48
<smaug____>
it sounds like a condition
10:48
<smaug____>
either while or do-while condition
10:50
<annevk>
smaug____: something like "Run spin the event loop with goal /goal/"?
10:50
<smaug____>
yes, something like that
11:10
<gsnedders>
MikeSmith: did you trying prodding with pdb, btw?
11:43
<espadrine>
related to html tokenization, shouldn't the HYPHEN-MINUS case indicate what state to switch to here? https://html.spec.whatwg.org/multipage/syntax.html#comment-end-state
11:44
<espadrine>
I'm used to seeing it specified everywhere
11:48
<zcorpan>
espadrine: it's not specified everywhere. when it isn't it means to stay in the same state :-)
11:48
<espadrine>
thanks!
12:06
<annevk>
smaug____: okay, I guess that can be done, not super high priority for now though
12:06
<annevk>
smaug____: there's some bigger problems with the event loop, such as lack of ES6 integration
12:06
<smaug____>
yeah, lack of defining how Promises should work
12:43
<MikeSmith>
gsnedders: did not yet pdb it yet, no. But it's been at least 2 weeks since I first noticed the problem, and I've not made time to investigate it further
13:07
<philipj>
zcorpan: I'm taking webvtt-webhook offline as I suppose it will never again be pinged
13:11
<zcorpan>
philipj: sounds good. i suppose it's broken with the move
13:56
<annevk>
philipj: what did that webhook do?
13:57
<philipj>
annevk: it generated a static copy of the spec using PhantomJS, then committed that to CVS
13:57
<annevk>
philipj: ah okay
13:57
<annevk>
philipj: so yeah, I guess we should setup webvtt.spec... and then just redirect that old copy
13:58
<philipj>
annevk: yep, MikeSmith says he can do the redirect
13:59
<philipj>
zcorpan: but if you don't want to check in the generated spec, then you'll still need some webhook to generate it from source
13:59
<philipj>
for mediasession I just check in the generated output, I kind of like seeing when Bikeshed made everything change
14:00
<zcorpan>
i could go either way with checking in generated version. in the csswg we typically just check in the source and have bikeshed run on the server, regenerating all the specs as necessary
14:02
<gsnedders>
MikeSmith: k
14:02
<gsnedders>
MikeSmith: am ill, so unlikely to dig recently
14:02
<gsnedders>
MikeSmith: recently? soon
14:56
<Mangle_Kawaii>
holis
15:05
<annevk>
zcorpan: until Domenic spreads the setup that Streams has I would prefer it if you check in the generated version too
15:05
<zcorpan>
annevk: sure
15:05
<annevk>
zcorpan: that way I can just curl/wget that from the server
15:09
<annevk>
zcorpan: the other thing that'd be useful if you kept the structure flat
15:09
<annevk>
zcorpan: no directories
15:09
<zcorpan>
annevk: ok. why?
15:11
<annevk>
zcorpan: easier to setup sync
15:11
<annevk>
zcorpan: that is, I can copy my existing script :-)
15:15
<zcorpan>
annevk: ok sure
15:19
zcorpan
gotta go
16:14
<Domenic>
annevk: MikeSmith: sorry I haven't had much time for reviews lately, but today should be good.
16:15
<annevk>
Domenic: not at TC39?
16:15
<annevk>
Domenic: prioritize MikeSmith's work, I'm in no rush
16:15
<Domenic>
annevk: at TC39, but today's topics look like I should have some in between time for reviews.
16:16
<Domenic>
Excited about getting URL straightened out though.
16:24
<annevk>
Domenic: slowly, but yes
16:25
<annevk>
Domenic: I guess I'll do Location too before we change that into distinct same-origin and cross-origin objects
16:26
<annevk>
Domenic: still need to think a bit about <a> and <area>, maybe tomorrow
17:47
<TabAtkins>
JonathanNeal: I just pushed the changes to Nesting.
17:51
<JonathanNeal>
Hurray! I'm out sick today, but anything I should take attention to?
17:51
<TabAtkins>
Nah, it's exactly what we talked about before.
18:01
<rbyers>
annevk: Regarding https://github.com/RByers/EventListenerOptions/issues/20, perhaps IRC (or a conference call if necessary) would be a more productive forum?
18:01
<rbyers>
.. It really sounds like we have the same end goal here, right? Make it easier for developers to reason about the performance implications of their handlers, while allowing more pages to be fast?
18:02
<TabAtkins>
rbyers: I'm opposed to that goal.
18:02
<TabAtkins>
I prefer artisan pages, hand-crafted and slowly enjoyed on your porch on a lazy Sunday morning.
18:02
<rbyers>
TabAtkins: Ok, I guess I was wrong about IRC being a more productive discussion forum ;-)
18:03
<TabAtkins>
^_^
18:06
<jsbell>
roc, annevk: You may also like https://gist.github.com/inexorabletash/280016e79188b6a28247
20:35
<MikeSmith>
whoah
20:35
<MikeSmith>
jsbell: I like the part where you say, "For those times when you don't care about your data getting corrupted, use this!"
20:38
<jsbell>
MikeSmith: ???
20:39
<MikeSmith>
jsbell: trolling )
20:39
<MikeSmith>
but that does seem like a possible footgun
20:40
<MikeSmith>
I would wonder, if it's made available, what's to prevent Web devs from using it when they should instead really be using the transactional API
20:41
<jsbell>
MikeSmith: indeed. You can lead a developer to ACID but...
20:41
<MikeSmith>
but instead they use this and end up muffing up their data and then they come screaming about Y U hurt my data??!!
20:41
<MikeSmith>
jsbell: yup
23:14
<Domenic>
Anyone understand hgroup enough to help with https://github.com/whatwg/html/issues/115 ?
23:22
<zewt>
well that's lovely, updated debian and a bunch of scripts broke because apparently lxml.cssselect is now case-sensitive
23:23
<TabAtkins>
SimonSapin: ^^^ what zewt just said; is lxml.cssselect case-sensitive somehow now?
23:25
<Domenic>
MikeSmith: what's a good way to trigger a build error deep in the file?
23:25
<zewt>
doc = html5lib.parse(html, treebuilder='lxml'); results = CSSSelector('#id A')(doc), had to change A to a (guess it could also be a change in the parser)
23:25
<MikeSmith>
Domenic: put in a stray end tag maybe
23:26
<Domenic>
sounds good
23:26
<Domenic>
Hmm if [[ "$WATTSI_RESULT" -ne "0" ]]; then => syntax error in conditional expression
23:27
<Domenic>
most of the conditionals in the file do not use [[ ]]
23:27
<Domenic>
oh nevermind
23:27
<Domenic>
I just mismatched my braces
23:28
<MikeSmith>
yeah we really should better be using the [[ ]] extended form everywhere, actually
23:30
<MikeSmith>
[[ ]] is just less portable. But if you use it even once in a script you might as well always use it. And there are cases the definitely require it
23:30
<Domenic>
MikeSmith: here's some output using the build server, going to try local now https://gist.github.com/domenic/68b7ab882afb6e6586d4
23:30
MikeSmith
looks
23:30
<MikeSmith>
so that looks correct
23:30
<MikeSmith>
that is expected output, right?
23:31
<MikeSmith>
damn look at those line numbers
23:31
<Domenic>
ok works
23:31
<Domenic>
yep
23:31
<Domenic>
just confirming it met what you expected
23:31
<Domenic>
wow local wattsi is fast
23:31
<MikeSmith>
103882 vs 105129 is quite a diffence but looks correct
23:31
<MikeSmith>
yeah Hixie's wattsi code is fairly amazing in terms of performance
23:32
<Domenic>
yeah 103882 is the correct source line i messed with
23:32
<MikeSmith>
his html parser is as fast as any other one out there
23:38
<MikeSmith>
Domenic: rock and roll
23:38
<Domenic>
\o/
23:38
<MikeSmith>
will rebase and squash the repo-switcher one shortly
23:39
<MikeSmith>
before that I need to clean up because I have to head into the office today and I'm in a somewhat Stallman-esque personal hygiene state from having been working at home so far all this week
23:42
<jgraham>
I didn't realise that was like Libraries of Congress for dirt
23:43
<Domenic>
lol i know the feeling
23:45
<wanderview_pto>
JakeA: is this still expected to work? https://jakearchibald.github.io/offline-wikipedia/?Hulk_Hogan
23:46
<wanderview_pto>
JakeA: I get a 404 from this resource load: https://wikipedia-cors.appspot.com/en.m.wikipedia.org/wiki/Hulk_Hogan?action=render
23:49
<wanderview_pto>
I haven't pretty-printed the sw.js, but it appears to be passing that URL through from the fetch event
23:55
<wanderview_pto>
JakeA: ah, it seems maybe the gh-pages branch just hasn't been updated in 5 months... I don't see appspot referenced from the main branch