History breaks in IE9 about exhibit3 HOT 15 CLOSED

Any idea how to fix this?

from exhibit3.

I've got some info about the problem though no idea how to fix it. exhibit's pushstate method invokes the history.js library, which in turn is supposed to trigger a statechange event that the exhibit controls listen for to rerender themselves. However, the logic of the history.js library in ie9 results in its returning without triggering statechange---I'm not sure why.

not sure if this is this a regression or has always been broken.

from exhibit3.

If anyone has discovered a solution to this, I would love to hear it. Otherwise it looks like I'll be reimplementing all of this without History, which sounds really unfortunate at this point.

from exhibit3.

I've been working at this but haven't yet figured out why it's going
wrong. the obvious easy fix is to disable history, but I'm not sure
that exhibit actually supports this right now. View updates are
triggered by state change events, and state change events are only
triggered by the history mechanism. So it isn't clear how to get by
without history.

I suspect the problem will go away in IE10, which supports html5
history api.

On Tuesday, April 02, 2013 10:35:58 PM, mherodev wrote:

If anyone has discovered a solution to this, I would love to hear it.
Otherwise it looks like I'll be reimplementing all of this without
History, which sounds really unfortunate at this point.

—
Reply to this email directly or view it on GitHub
#100 (comment).

from exhibit3.

I'm running into the same issue now. Is there any progress on this? I'm pretty much a newb at coding and I don't know where to start to try and fix this. We are using the replaceState method, and the same thread comes back with a #./ inserted into the URL.

I've seen a few types of solutions but none are seem to work. If you don't have the fix, then are there any graceful degradation/fallback code suggestions that will allow me to keep the history and just remove the #?

from exhibit3.

I'm aware of the problem and have been trying to get to the bottom of
it on and off for weeks. Unfortunately the code involved is highly
asynchronous/event driven, and most of my attempts to trace things in
debug mode make the problem go away. If anyone is familiar with
history.js and can provide insight, I'd love some help; meanwhile I
will keep trying.

On Wednesday, July 03, 2013 9:21:47 PM, Jannaee Sick wrote:

I'm running into the same issue now. Is there any progress on this?
I'm pretty much a newb at coding and I don't know where to start to
try and fix this. We are using the replaceState method, and the same
thread comes back with a #./ inserted into the URL.

I've seen a few types of solutions but none are seem to work. If you
don't have the fix, then are there any graceful degradation/fallback
code suggestions that will allow me to keep the history and just
remove the #?

—
Reply to this email directly or view it on GitHub
#100 (comment).

from exhibit3.

I use History.js in the Historical Weather piece of the Energy Trader. Is
that why I was included on this email? Feel free to check out Historical.js
in the Widgets folder of that project and see what I do there. As far as I
know, it works with IE9.

On Wed, Jul 3, 2013 at 1:47 PM, David Karger [email protected]:

I'm aware of the problem and have been trying to get to the bottom of
it on and off for weeks. Unfortunately the code involved is highly
asynchronous/event driven, and most of my attempts to trace things in
debug mode make the problem go away. If anyone is familiar with
history.js and can provide insight, I'd love some help; meanwhile I
will keep trying.

On Wednesday, July 03, 2013 9:21:47 PM, Jannaee Sick wrote:

I'm running into the same issue now. Is there any progress on this?
I'm pretty much a newb at coding and I don't know where to start to
try and fix this. We are using the replaceState method, and the same
thread comes back with a #./ inserted into the URL.

I've seen a few types of solutions but none are seem to work. If you
don't have the fix, then are there any graceful degradation/fallback
code suggestions that will allow me to keep the history and just
remove the #?

—
Reply to this email directly or view it on GitHub
#100 (comment).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/100#issuecomment-20436879
.

from exhibit3.

Yes, I assume history.js works with IE9 or there would be more complaints as it is widely used. However, it isn't working with the exhibit codebase. Tracing its execution takes me to some code that doesn't make a lot of sense; does anyone know if there is any history.js documentation (beyond the code) that explains what it is doing?

from exhibit3.

I made a simple workaround for supply this problem. On page load I check if page url is the same as i expect (like http://example.com/something) and if not (like http://example.com/something#./something?&_suid=.....) I reload the page with a default value (set for example at http://example.com/something).

It is not a fix and you will loose all elements selected but makes IE not triggering errors anymore.

var correctURL = "/something";
var domainPrefix = location.protocol+'//'+location.hostname+(location.port ? ':'+location.port: '');

var currentLocation = location.href;
var correctLocation = domainPrefix + correctURL;

if(currentLocation != correctLocation){
    location.href = correctLocation;
}

from exhibit3.

And I forgot to mention that I replaced jquery.history.js with this version:

https://github.com/browserstate/history.js/blob/master/scripts/bundled-uncompressed/html4%2Bhtml5/jquery.history.js

from exhibit3.

I've made what might be a more complete fix, currently serving from
http://people.csail.mit.edu/karger/ExhibitK/dist/ . Can you let me
know if it works for you?
On 7/23/2013 6:01 PM, Jonathan wrote:

I made a simple workaround for supply this problem. On page load I
check if page url is the same as i expect (like
http://example.com/something) and if not (like
http://example.com/something#./something?&_suid=.....) I reload the
page with a default value (set for example at
http://example.com/something).

It is not a fix and you will loose all elements selected but makes IE
not triggering errors anymore.

var correctURL = "/something";
var domainPrefix = location.protocol+'//'+location.hostname+(location.port ? ':'+location.port: '');

var currentLocation = location.href;
var correctLocation = domainPrefix + correctURL;

if(currentLocation != correctLocation){
location.href = correctLocation;
}

—
Reply to this email directly or view it on GitHub
#100 (comment).

from exhibit3.

Unfortunately now I can only try on IE8 and the version you linked doesn't
work properly. My situation is a map with multiple markers of different
types with a simple facet for filtering. What happens with your version is
that when I press on a filter label it triggers only suid update but
nothing changes on page until I refresh. When I refresh page I can see the
selection I made.

2013/7/24 David Karger [email protected]

I've made what might be a more complete fix, currently serving from
http://people.csail.mit.edu/karger/ExhibitK/dist/ . Can you let me
know if it works for you?
On 7/23/2013 6:01 PM, Jonathan wrote:

I made a simple workaround for supply this problem. On page load I
check if page url is the same as i expect (like
http://example.com/something) and if not (like
http://example.com/something#./something?&_suid=.....) I reload the
page with a default value (set for example at
http://example.com/something).

It is not a fix and you will loose all elements selected but makes IE
not triggering errors anymore.

var correctURL = "/something";
var domainPrefix =
location.protocol+'//'+location.hostname+(location.port ?
':'+location.port: '');

var currentLocation = location.href;
var correctLocation = domainPrefix + correctURL;

if(currentLocation != correctLocation){
location.href = correctLocation;
}

—
Reply to this email directly or view it on GitHub
#100 (comment).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/100#issuecomment-21472025
.

from exhibit3.

I made some additional corrections, possibly after you tried. Can you
try again and let me know what happens? Others have reported success on
IE8. The fix has been pushed to
http://api.simile-widgets.org/exhibit/HEAD/ if you want to try linking
to that. If it still doesn't work for you, please post a link to the
broken exhibit.
On 7/24/2013 9:11 AM, Jonathan wrote:

Unfortunately now I can only try on IE8 and the version you linked
doesn't
work properly. My situation is a map with multiple markers of different
types with a simple facet for filtering. What happens with your
version is
that when I press on a filter label it triggers only suid update but
nothing changes on page until I refresh. When I refresh page I can see
the
selection I made.

2013/7/24 David Karger [email protected]

I've made what might be a more complete fix, currently serving from
http://people.csail.mit.edu/karger/ExhibitK/dist/ . Can you let me
know if it works for you?
On 7/23/2013 6:01 PM, Jonathan wrote:

I made a simple workaround for supply this problem. On page load I
check if page url is the same as i expect (like
http://example.com/something) and if not (like
http://example.com/something#./something?&_suid=.....) I reload the
page with a default value (set for example at
http://example.com/something).

It is not a fix and you will loose all elements selected but makes IE
not triggering errors anymore.

var correctURL = "/something";
var domainPrefix =
location.protocol+'//'+location.hostname+(location.port ?
':'+location.port: '');

var currentLocation = location.href;
var correctLocation = domainPrefix + correctURL;

if(currentLocation != correctLocation){
location.href = correctLocation;
}

—
Reply to this email directly or view it on GitHub

#100 (comment).

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/100#issuecomment-21472025
.

—
Reply to this email directly or view it on GitHub
#100 (comment).

from exhibit3.

You're free to keep discussing here if need be, but it sounds like this issue is potentially solved, and as mentioned earlier, it generally deals with a different code base. Closing.

from exhibit3.

Note that the proposed solution is here: simile-widgets/exhibit#15

from exhibit3.