27817 2015-01-13 02:56:47 +0000 Value of lastModified probably shouldn't change during the lifetime of the document 2015-08-28 16:18:04 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME https://html.spec.whatwg.org/#sandboxCookies P3 normal Unsorted 1 contributor ian annevk bzbarsky ian josh mike zcorpan contributor oldest_to_newest 117057 0 contributor 2015-01-13 02:56:47 +0000 Specification: https://html.spec.whatwg.org/ Multipage: https://html.spec.whatwg.org/multipage/#sandboxCookies Complete: https://html.spec.whatwg.org/#sandboxCookies Referrer: Comment: Value of lastModified probably shouldn't change during the lifetime of the document Posted from: 98.110.194.132 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:37.0) Gecko/20100101 Firefox/37.0 117058 1 bzbarsky 2015-01-13 02:57:24 +0000 In particular, the "current time" thing should be a snapshot taken at a well-defined point in document setup instead of having a lastModified that changes every time you access it. In my opinion, of course. 117063 2 zcorpan 2015-01-13 08:32:41 +0000 Why? 117071 3 bzbarsky 2015-01-13 13:20:22 +0000 Why which? Why should it not change? Conceptually, lastModified is when the HTML the browser is rendering was last modified. This can obviously be sometime before the browser received the HTML, but, still conceptually, it can't be _after_ the browser has received it, because it's already received it. So let me turn this around. Why should this value possibly change during the document lifetime? That's completely nonsensical behavior. 117077 4 zcorpan 2015-01-13 15:37:28 +0000 (In reply to Boris Zbarsky from comment #3) > Why which? Why should it not change? Right. > Conceptually, lastModified is when the HTML the browser is rendering was > last modified. This can obviously be sometime before the browser received > the HTML, but, still conceptually, it can't be _after_ the browser has > received it, because it's already received it. > > So let me turn this around. Why should this value possibly change during > the document lifetime? That's completely nonsensical behavior. It's what the majority of implementations do (WebKit/Blink/IE11/Presto). So it's a shorter path to interop for Gecko to change to match everyone else. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3363 117079 5 bzbarsky 2015-01-13 15:48:31 +0000 That's fair, but it seems to me that converging on nonsensical behavior is not a success story, even if it achieves interop. If we can't achieve interop in any other way, then maybe it's worth it. But it's very definitely a tradeoff, and I'm not convinced we can't achieve interop in any other way. 117113 6 ian 2015-01-13 23:10:58 +0000 lastModified is crazy town anyway. I would just pretend it wasn't there. 117128 7 bzbarsky 2015-01-14 02:15:03 +0000 I would totally love to do that, but people are insisting on writing test suites that test its behavior. 117144 8 zcorpan 2015-01-14 09:29:16 +0000 (In reply to Boris Zbarsky from comment #5) > That's fair, but it seems to me that converging on nonsensical behavior is > not a success story, even if it achieves interop. In this case I think both behaviors are basically not useful. The author wants the date when the document was actually last modified, not the current date and not the date when the document was loaded (nor the date when the server generated the page and put that in Last-Modified). So which we pick doesn't matter as far as usefulness of the API goes. 117224 9 ian 2015-01-15 19:26:05 +0000 What do browsers do today, with respect to the issue in this bug? 117225 10 ian 2015-01-15 19:27:22 +0000 Looking at the test in comment 4, it seems like the spec matches the majority of implementations already. I see no value in changing the spec here. 117230 11 bzbarsky 2015-01-15 19:43:44 +0000 OK. I'm not going to waste more time on this; I guess we'll just update to the pointless behavior everyone else picked, yet again...