smaug: ping/

*?

smaug: Document::Destroy() isn't guaranteed to be called for every document, right?

right

smaug: why do we report use counters from there then?

smaug: i.e., aren't we missing use counters?

I think we were reporting use counters anyhow for non-data documents only

smaug: I was looking into how to hook a use counter per CSS property into telemetry

smaug: but is Document::Destroy() called for iframes and such? If so, in which order does that happen?

it is called for iframes

order is whatever order contentviewer gets destroyed

does order matter?

smaug: ah, cool... for any Document::Destroy() that happens, then I guess we have the guarantee of the iframe's Document::Destroy() being called before the parent, right?

smaug: right now it does not

smaug: but I want to make SetPageAndDocumentUseCounter just a bit flip

I don't know why there would be such guarantee

smaug: and propagate to the "page" when we report the other use counters

ah, right

smaug: I assume the content viewer of an iframe gets destroyed when we tear down the frame tree of the parent

smaug: which must necessarily happen before the parent's Destroy() is called

Maybe mod. bfcache or what not? I'm not sure how bfcache works with iframes

I think we might have a bug

use counter reporting should be later

edgar: ^

smaug: well, right now it doesn't matter, but it matters for my purposes

smaug: right now we eagerly propagate to the page

but you want some different setup because ?

smaug: because I want CSS use counters for all properties, and it cannot be something expensive

smaug: (where I == product, I guess)

and it is currently too expensive ?

smaug: right now it's not, but it's not hooked into telemetry. If I wanted to record the page use counters it'd be too expensive, yeah

smaug: basically, it is not right now, because we record a bit in the document. But if I have to do the "propagate to page" dance then that wouldn't make me happy

emilio: because you don't want to do all the parent doc finding etc

smaug: right

ok, makes sense

smaug: ok, I'll send a patch changing the existing setup, thanks for pointing me at DestroyContent()... I'll also keep an eye on the data this week to ensure we keep reporting the same

smaug: (this makes the setup for image documents and regular documents more similar, which is kinda nice, I think)

thanks for asking. Use counter setup might still require some tweaking, depending on these kinds of new requirements

smaug: how is the document / page distinction going to work with fission?

Well, the implementation will need to be changed

I guess one will have to send data to the top browsing context

emilio: I'm guessing document/page refers to data documents and non-data documents etc?

nika: no, page is "top level content document or any subdocument" in this case, afaict

So documents which are active in a nsGlobalWindow at some point sorta?

emilio: just wanting to figure out if I already have an answer for how fission is handling it

nika: we only propagate use counters to parent documents in-process, so pretty sure we're not handling it, or are treating every oop iframe as top-level

nika: see searchfox.org/mozilla-central/rev/9…65b86c6/dom/base/Document.cpp#14358 (I'm changing the setup a bit as we speak but...)

for webidl, if I have a [Func="..."] annotation, how do I figure out the `this` object, or is that impossible or something?

ie on instance of Foo, for property bar, I want whether or not it's there to depend on *handwave* something else about the instance of Foo

Gijs: do you know what's responsible for re-filling form values on refresh?

bdahl: not 100%... I assume session restore but not super sure.

hmm...yeah i thought it was something in there, but all the places i keep looking at don't seem to be it

bdahl: searchfox.org/mozilla-central/rev/e…ionstore/ContentRestore.jsm#135-139 ?

hm, maybe not

other guess would be searchfox.org/mozilla-central/sourc…/components/satchel/FormHistory.jsm

bdahl: maybe set a breakpoint in htmlinputelement value setter and refresh?

was only getting one triggered for the url bar, but there's also SetValueInternal

found it now

and i think i see the issue

bdahl: so where is the code that does this, out of interest? :)

Gijs: it's triggered from searchfox.org/mozilla-central/rev/e…af/dom/xml/nsXMLContentSink.cpp#966

which we don't have when using the prototype

i'm going to extract that "if" out of the xml content sink and the html tree builder and put it all on one place so they all share it

and same with DoneAddingChildren

seems bad to have that copied in three places that need to be in sync

nika: ping?

mccr8: ping?

emilio: Sorry, in a meeting

emilio: What's up?

nika: np, I think mccr8 may know some / better.

nika: Do you know what's the consequence of increasing searchfox.org/mozilla-central/rev/e…ild_scripts/gen_histogram_phf.py#9?

nika: I see mccr8 reviewed that... But you're to blame for the PHF code :)

emilio: Ah, yeah. It just changes the size of a table

nika: I basically added a bunch of telemetry histograms, and the build time blows up if I keep it at 512

emilio: Just a binary size increase which is super small

nika: ok, so super-small is what I was looking for

nika: does doubling it sound fair?

Yeah, it has to be a power of 2 to be efficient iirc

emilio: It's like N shorts, so it's almost irrelevant

nika: ahá, amazing. Thanks!

nika: congrats for being an xpcom peer btw! ^.^

nika: congrats^W^W^W^W^Wdolences I guess :)

"bringing the excitement of XPIDL to Rust"

nice

thanks :-)

asuth: ping

asuth: was hoping you can point me to the code that prevents IndexedDB from working because we're in a private window? :)

I'll start digging...

johannh: factory methods like at searchfox.org/mozilla-central/source/dom/indexedDB/IDBFactory.cpp#138 like to call out to helpers like searchfox.org/mozilla-central/source/dom/indexedDB/IDBFactory.cpp#335 that then check if storage is allowed

but there are also checks lower down in that first method to save off the private-browsing mode

asuth: specifically, I was wondering if there could be an exception if a principal doesn't have the privateBrowsingId but is still in a private browsing window

asuth: it doesn't seem to work off-hand

(just opening a page in a private window that has its pBId stripped)

(trying to solve bug 1427986 while solving bug 1554805, but I don't mind if they stay separate)

anyway, thanks for the info!

ok, doesn't seem trivial, I'll drop it

johannh: Yeah, I think there are a lot of special-cases around webextensions that complicate things in terms of what they should be able to see versus how they should be partitioned from each other/etc.

Also that background pages are implemented as real pages that you can't see is weird.

yup

bdahl++