I believe so, but I'll double check and will email you off this thread.
\i
On Thu Nov 13 2014 at 11:06:37 PM Evan Stade est...@chromium.org wrote:
That sounds like crbug.com/354257 which was fixed in March. Are you sure
this is still a problem on newer versions of Chrome?
On Thu, Nov 13,
On Nov 10, 2014, at 2:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/10/14, 5:31 PM, Florian Rivoal wrote:
That said, the labeled control also maintains a list of references to the
associated labels, so there is no particular difficulty involved in finding
them.
The difficulty is not
On Thu, 13 Nov 2014, cowwoc wrote:
In any case, the question seems to be whether history.replaceState()
should be honored in beforeunload. Individually, each one is very well
defined, but I don't see any discussion of what should happen when the
two are used together.
You just follow
On 14/11/2014 6:39 PM, Ian Hickson wrote:
On Thu, 13 Nov 2014, cowwoc wrote:
In any case, the question seems to be whether history.replaceState()
should be honored in beforeunload. Individually, each one is very well
defined, but I don't see any discussion of what should happen when the
two are
On 2014-11-14 19:10, Evan Stade wrote:
The problem is that we don't think autocomplete=off is used judiciously.
Could you make a compromise and respect autocomplete=off for only
type=text, and ignore autocomplete=off for all other input types as
you guys planned?
And then look at how the
On 2014-11-15 02:08, cowwoc wrote:
Personally the way I build apps these days is to just serve static
files over HTTP, and do all the dynamic stuff over WebSocket, which
would sidestep all these issues.
You mean you have a single-paged application and rewrite the
underlying page
On Fri, 14 Nov 2014, cowwoc wrote:
1. Say we have two pages: OLD and NEW.
2. OLD contains a link to NEW.
3. I start off on OLD and click on the link.
4. The above logic runs (beforeunload event handler changes the URL
using history.replaceState() from OLD to CHANGED)
5. The browser
On 14/11/2014 8:56 PM, Roger Hågensen wrote:
On 2014-11-15 02:08, cowwoc wrote:
Personally the way I build apps these days is to just serve static
files over HTTP, and do all the dynamic stuff over WebSocket, which
would sidestep all these issues.
You mean you have a single-paged
On 2014-11-15 03:07, cowwoc wrote:
On 14/11/2014 8:56 PM, Roger Hågensen wrote:
Did you also use a URL parameter to indicate which cookie the server
should look in? I think my solution is problematic in that I have to
go through GetTabId.html on page load (which looks ugly) and even
worse I
