On Wed, Jan 6, 2016 at 8:52 AM, Honza Bambas <[email protected]> wrote:
> I think this kind of caching should do devtools, not necko. If I read you correctly, Honza, you're saying devtools should cache the original page content, not necko. But I'm not sure that this is possible--I assume they don't have access to the original data, just the post-parsed DOM and whatnot. (Is that true?) >> some sort of flag that indicates it should be invisible to cache reads unless CACHE_HIDDEN_COPY is again present. > > Such a devtools cache is very hard to build on the Necko level. We need new flags or somehow expose the info on the loadgroup. So I understand that we'd need a new flag. I don't understand why that would be very hard (but I don't know the cache code). Couldn't we just have docshell or uriloader, etc, set the HIDDEN_COPY flag if devtools is active? > If we use HTTP force caching, we need to ensure it goes away with closing the devtools window. Being in-memory only might be the way here. I know in the old cache we had namespaces (and with B2G we have storage per appid). Could we just use some magic appID for items that we force-cache for devtools, and then blow it away either at shutdown or when devtools are closed? > this caching enforce on the HTTP level would actually break the web - the behavior would simply be different. Well, right--we'd only want to read hidden entries if it's the devtools code that's asking for them. But that should be a matter of having a loadFlag. > nsIRequest::LOAD_FROM_CACHE should disable revalidation, and give you what > is in the cache. It falls back on the network if the resource is missing, > but if you combine it with nsICachingChannel::LOAD_ONLY_FROM_CACHE, it > would fail it the resource wasn't cached. Tom: could you do a quick experiment to see what % of resources you wind up getting correctly (i.e. from the cache, without revalidation or hitting the network) if you use LOAD_FROM_CACHE? I'm wondering if using that (plus maybe LOAD_ONLY_FROM_CACHE, as described above, so we could at least warn developers when we did need to re-fetch the source), would be good enough for now. > Lot of work. Don't we have more important stuff to do? Good question. I don't know the answer yet. I think the results of the experiment I suggest would be useful--if we get a high enough hit rate in practice, then maybe we don't need to do the HIDDEN_COPY stuff for now. Jason On 12/20/2015 0:36, Jason Duell wrote: > >> On Fri, Dec 18, 2015 at 6:15 PM, Ehsan Akhgari <[email protected]> >> wrote: >> >> On 2015-12-18 4:56 PM, Tom Tromey wrote: >>> >>> I mentioned this on #necko the other day. >>>> >>>> We've had a "re-fetching" problem in devtools for a while now. >>>> >>>> The basic issue is that the platform drops the original text of some >>>> things, like style sheets. (Instead just the parsed form is preserved.) >>>> >>>> So, in order to make some tools work with the source text, devtools >>>> re-fetches the sources. However, this is sub-optimal -- maybe the >>>> sources have changed on the server, leading to confusing results. >>>> >>>> We were wondering if there was some way we could solve this problem. >>>> >>>> One idea we had is to always cache these things, in a way that would let >>>> the devtools retrieve them. Is this possible? >>>> >>>> We can't cache the resources if the web server tells us "don't cache >>> this", so even if we use things such as LOAD_ONLY_FROM_CACHE, we still >>> need >>> a solution for that case. >>> >>> Or ... some other idea here. >>> How about forcing Gecko retain the original source text when devtools are >>> being used? >>> >> >> >> Sounds like we need something like a CACHE_GECKO_COPY flag that keeps a >> "secret" cache only for internal gecko use? >> > > If that would be enforced only for active devtools, we could go with that. > > >> 1) if the resource would normally be cached, does nothing (the resource >> gets cached normally) >> 2) If the resource wouldn't be cached, cache it (perhaps only in RAM? >> > > Easy to evict on devtools close but easy to waste memory... > > Or >> maybe we'd need that only if INHIBIT_PERSISTENT_CACHING is set), with some >> sort of flag that indicates it should be invisible to cache reads unless >> CACHE_HIDDEN_COPY is again present. >> > > Such a devtools cache is very hard to build on the Necko level. We need > new flags or somehow expose the info on the loadgroup. If we use HTTP > force caching, we need to ensure it goes away with closing the devtools > window. Being in-memory only might be the way here. Use the defer-caching > capability from bug 1203113 could be other way to achieve it (we are save > with eviction on devtools close and also don't waste memory!) > > Lot of work. Don't we have more important stuff to do? ;) > > Also, this caching enforce on the HTTP level would actually break the web > - the behavior would simply be different. I think this kind of caching > should do devtools, not necko. > > > -hb- > > >> Jason >> >> P.S. Honza/Michal: right now nsIRequest.idl says that "For HTTPS, >> [INHIBIT_PERSISTENT_CACHING] is set automatically." That's out of date >> now >> IIRC--we should change the comment. >> _______________________________________________ >> dev-tech-network mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-tech-network >> >> > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > -- Jason _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
