- From: <bugzilla@jessica.w3.org>
- Date: Mon, 12 Jan 2015 10:59:45 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27790 --- Comment #8 from Philip Jägenstedt <philipj@opera.com> --- (In reply to Boris Zbarsky from comment #5) > > my take is that returning a new object every time isn't terrible enough > > It's pretty terrible. It's a behavior that only C++ implementors seem to > think is OK for a JS property get.... Not least because it's simple for > them to do. Guilty as charged, I didn't even consider this problem when implementing these properties in Presto. > > Ensuring that .buffered returns the same object as long as it hasn't changed > > since last access > > Can it change without the event loop spinning or script in some way invoking > browser APIs? Because if not, then this is clearly the correct solution, > imo. I think that's true for MediaSource as the append/remove bits are all async. HTMLMediaElement can synchronously detach from its backend by e.g. HTMLMediaElement.load(), but that's in response to an explicit call. I can think of no way 'video.buffered === video.buffered' to ever be false with a definition like "return the same object iff the ranges are identical to the previously returned object." I don't think MSE should do this if HTML doesn't, though. Always returning the same object and having that be live is also possible, but I'm not a fan of live objects, and it could possibly break existing code that keeps old ranges in order to compare with new ones. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 12 January 2015 10:59:50 UTC