> upon shutdown instead of waiting for all I/O events to happen > It seems to me like, given the nature of cache data, we should accept some data loss But I agree we shouldn't let this particular bug block shutdown. Well, in the general case with a priority scheme where lower priorities never get run if higher ones gobble all the time, you could make the case that the gobbler is the bug. This is a cache bug as far as I'm concerned. > Really it should not be possible for addons or content to starve cache shutdown in the I assume the same is true for lowering Close event priority. In the general case of browsing we get significantly faster page load times by prioritizing cache hits (reads) over storing new cache entries (writes), which then get stored as things quiet down. > could you please comment on why the CLOSE event is a lower priority than other We don't have clear steps to reproduce and others have reported the problem without the Skype add-on installed, so I don't think it's fair to continue blocking it. If there was clear evidence that this add-on (the latest version in particular) is the culprit, rather than YouTube or other factors, I would keep the block up.
> today is the kick-off of the big Firefox 42 marketing campaign. > Today is a particularly bad time to unblock Skype Click to Call because I don't have any stats on their version distribution to tell for sure. If the add-on is only installed or updated through their application installer, it's likely that many users would be stuck with older versions. It depends on how they handle automatic updates, if at all. > even if the add-on is not distributed through AMO? > Click to Call add-on? Shouldn't users have been receiving Skype updates, > Jorge, wouldn't we expect users to have the most recent version of the Skype (In reply to Chris Peterson from comment #41)
0 kommentar(er)
