I have a site with anchor navigation (like gmail, when the anchor value changes a new content for a page is loaded with ajax). In Firefox, when I change the anchor (with js or with a page) a new item in the history is created and works perfectly. But in IE6 it doesn't stores this new item and the back button doesn't work as expected.
Is there anyway to add this new item using javascript?
This is possible because gmail does it but I don't know how it does it.
I've done a lot of work with history and using the hash. Almost all of the existing history plugins have some sort of gap in them. The one I've used that's pretty close to perfect is this one which is a jQuery plugin:
http://www.mikage.to/jquery/jquery.history.js
It was updated in March of this year handles IE 8 issues and it also deals with IE6 pretty successfully. One thing I've noticed is that IE really hates having ? in the hash after the #. It stops properly handling the hash when the ? is present. Even this one I think needs a little patch for the ?, I really need to send that along to Mikage. The way to handle this is instead of using location.hash in the plugin when referencing the hash, use this function:
function getHash(loc) {
loc = loc.toString();
if (loc.indexOf("#") != -1)
return loc.substring(loc.indexOf("#"));
else return "";
}
So in those spots where you need the hash, pass location the to function...
getHash(location)
...instead of using location.href. But note that for IE, because it's using the iframe, you want to use iframe.location instead.
getHash(iframe.location)
Yahoo's Bug
You can see that Yahoo doesn't gracefully handle ?'s in IE when looking at this URL:
http://developer.yahoo.com/yui/examples/history/history-tabview.html#tabview=tab1?7236471234
It should just ignore the non-existent module, (which it does for other names which have no ?'s in them). But it raises a JavaScript error when a ? is in the URL.
(I will extend this list in a moment)
Really Simply History
Frankly, it's primary issue seems to be it's gone dormant. I've experienced this issue and just didn't want to dig through it:
Also, even though no changes appear to
take place on the page while I travel
backward through the history, the back
functionality will return once I hit
the pages that I had been navigating
before the one using RSH. So, if I
clicked on four links in the RSH page,
back functionality will return after
I have clicked on the back button four
times. I hope that makes sense.
I think you may have a different problem. IE6 certainly handles # links in history as it should for me on any given test page, so I believe either you have broken this in some way or you have a bug with your particular version of IE.
I suggest you try a few different copies and versions of IE6 on other machines to rule out the latter, and then try simplifying your code and rebuilding it to see if and when the problem appears. Turning off JS may (html depending) be a fast way to test this.
If all else fails I suggest you look at Really Simple History which (last time I checked) solves almost all JS/history problems you can throw at it.
Yahoo has a history manager too.
Related
I actually want to add a button to Gmail. When someone opens a email, he/she sees a button and when someone clicks on it, I add a function to it. I know one way but it's very intensive where I use setInterval() every 300 ms and run a function to check if it's Gmail or not and then add a button dynamically. I need something less intensive because I don't want people to have problems running my add on.
I want it all from my add on script so that I can easily communicate between other functions of my add on.
To add to pages it depends. Pages can do many tricky things (like GitHub using PJAX see this addon on how it was done).
Method 1 - addEventListener to window or gBrowser
But most usually you can catch a DOMContentLoaded or load event. Template HERE.
Method 2 - Observe http-on-examine-response and loadContext
If the URL of the nsIHTTPChannel matches your pattern then get the contentWindow from the loadContext and then manipulate. I need to make a clean template for this but you can see some messy ones: here and here
Method 3 - Add ProgressListener
ProgressListeners are nice because it helps you catch anchor changes, and usually when sites ajax and change page they change the url somehow but it doesnt really load a new page. I'm working on a template for this but it's not ready yet.
Info about addEventListener
If you add event listener in some situations it works for when 3rd parameter is true or when false. If you find one that works for your situation it will always work.
To figure out what combination works for you install this addon: event-listener-experiment-DOMC-and-load it's on GitHub so you can install straight from GitHub with this addon GitHub Extension Installer
Install that addon then navigate to your page, look in the browser console to see what feedback you're getting. It will tell you which works for you. If you need more help tell me the site and I will help you figure it out.
Here's a bootstrap template you can use once you figure out the combination:
I'm working on a website where one of the pages has a list of articles and an option to filter these based on certain keywords. All the keywords are links and listed to the right of the list. In order to get the correct URL's, the links on each keywords hold part of the ajaxURL that would give the correct response for the given keyword. In addition, I got a script that adds a 'click'-event to all links and appends the last required parameters to the ajaxURL. I "reload" the list by using jQuery's 'load'-function, like this:
$('a.keyword').click(function(event){
event.preventDefault();
// Other logic
$('.list').load(ajaxURL);
}
However, when using the filter in IE9 the content of 'ajaxURL' is loaded into the entire page. That is, the entire page is replaced with the resulting list. I figured this could be a problem of only using 'event.preventDefault()' on the 'click'-event I got on each link, so I added a variety of alternatives:
event.stopPropagtion()
return false
if(event.preventDefault){
event.preventDefault();
} else {
event.returnValue = false;
}
After hours of debugging, trying different combinations of these and trying IE7, IE8 and IE9 using the developer tool provided in IE, I realized that the first time I open the page with IE9 (without opening the developer tool), I get the problem described above. However, when I open the developer tool and selects IE8 it all works perfectly! The same happens when I change it back to IE9! (In this case I used all the alternatives above.)
For some reason, these transitions make it work! I can't figure out how to fix this.. I can't force users to open developer tool and switch mode to make i work. :P Any ideas? Does the developer tool add something that could do this?
I appreciate any help on the matter! :-)
PS. It works just fine in Chrome, ++.
The only thing I can think of is having console.log() in your script. That statement throws a Javascript error in IE up until you open the Developer Tools.
If that occurs earlier than the code you provided in the question then the rest of your script probably won't get evaluated, and your event handlers won't be bound at all, causing the links to just be regular links.
Is there an easy way to save ajax requests into a browser's history so that when you use the back button it will preserve the last state of the DOM?
Websites like twitter and digg that use an ajax pager have a usability flaw where if you click next page several times then click away from the site and then return using the back button, you lose your place in the viewport since the DOM is restored to the first initial request.
I noticed safari actually preserves the dom after a few ajax requests on some sites.
Here is an example, Goto http://13gb.com, Click next a few times then click on an image and then click your back button. On webkit it preserved the last DOM state, but on gecko and ie it does not.
What would be the easiest way to replicate this functionality on other browsers?
I'm not the first person to tackle
this type of problem. I've drawn
inspiration and know-how from several
places to get this up and running:
The original bookmark/back button fix,
as used by Flash developers for a
little while now:
http://robertpenner.com/experiments/backbutton/flashpage.html
I've not actually looked at how they
implemented their solution but this is
where I got the idea for replacing
Robert Penner's frames with iframes:
http://dojotoolkit.org/intro_to_dojo_io.html#so-about-that-thorny-back-button
Rich Rutter's use of the hash for
bookmarking:
http://clagnut.com/sandbox/slideshow.html#5
For this little experiment I've used Harry Fuecks' JPSpan
It's a fantastic framework that makes the methods you define in your server-side PHP classes available to your Javascript via XmlHttpRequest.
It's the simplest way I've come across
to get started with AJAX. I had the
guts of my demo up and running in
about 10 minutes! I'm using
Algorithm's Timer object:
http://codingforums.com/archive/index.php/t-10531.html
And Scott Andrew's cross-browser event
handler:
http://scottandrew.com/weblog/articles/cbs-events
Source: http://www.contentwithstyle.co.uk/content/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps
For jQuery:
https://stackoverflow.com/questions/116446/what-is-the-best-back-button-jquery-plugin
You may be interested in the jQuery History plugin:
http://tkyk.github.com/jquery-history-plugin/
I just came across some odd behavior in Firefox 3.6/Mac. I suspect that it's general Firefox behavior, though.
I created two dead-simple test pages that change the window.location.href property to navigate to new URL:
http://troy.onespot.com/static/stack_overflow/redirect.html
http://troy.onespot.com/static/stack_overflow/redirect_timeout.html
If you try the following with either file:
Open a new/blank browser tab.
Paste the URL and hit "Enter".
You'll notice one difference between the two: using the first link, the browser's "Back" button is disabled; using the second, it's enabled and works as I'd expect it to.
The only difference between the two scripts is that the latter sets a one-second timeout before changing window.location.href.
I don't know why this happens, and I'm trying to achieve the behavior of the second script (where the "Back" button continues to work as expected) without causing any delay for the user.
My best guess is that maybe Firefox treats an immediate "redirect" by setting window.location.href the same as using the window.location.replace() method, since I think it's common for developers to use the former when they meant to use the latter. Maybe using setTimeout, since that causes the code to run asynchronously, defeats this behavior. Could that be the case?
I haven't experimented with the minimum value for setTimeout to achieve the desired effect, but I'll do that now. I would like to figure out why this happens exactly, though.
Thanks!
You are right in assuming that setting location.href while a page is loading is treated as a replace. There are in fact two separate behaviours.
The first is that setting location.href from script running as the result of parsing a tag is always interpreted as a replace. This was implemented to mirror Netscape 4 behaviour and subsequently tweaked.
The second is that any new document loaded as the result of an onload handler is also always interpreted as a replace. This was implemented and also tweaked.
But I'm curious as to why you are so keen to do this, as means that users would have to use the Back drop-down menu to go to the page before your page. (Going back one page would be no use if it kept on redirecting them to the current page.)
My best guess is that maybe Firefox treats an immediate "redirect" by setting window.location.href the same as using the window.location.replace() method, since I think it's common for developers to use the former when they meant to use the latter. Maybe using setTimeout, since that causes the code to run asynchronously, defeats this behavior. Could that be the case?
I've been told your guess is correct, but now that I look, there's doesn't appear to be any mention of this requirement in the HTML5 spec (linking to the most relevant page, since it's hard to link to the absence of requirement).
Is there any way to avoid firefox and IE to reload the page adding the hash-tag to the url.
Due to that I have to refine results by time with adding &as_qdr=d to the end of url, I have a problem with these hashtags in url, because anything behind them seems to be unfunctional.
It does not happen with Chrome, but Firefox reloads the page after query adding this nightmare hash:
d?=¿)a¿?)!!m!!"!"·n
My form is here
I need a javascript to block Firefox (at least) to reload adding the hash-tag
I know this is an old question but I had a similar problem.
Turns out it was the href="#" when handling the onclick event.
Use href="javascript:void(0)"
A more complete answer is here
The linked site doesn't give much to test/work with. Maybe it's the language barrier, but it was not entirely clear to me how I am supposed to interact with the site so that I can try to reproduce the problem. In the future questions, try to add clear steps how to reproduce the problem.
At least, I would revise the way of appending query parameters to end of URL. The symptoms make it much look like that you're blindly appending them to the very end of the entire URL without determining/filtering the URL itself. I suggest you to use window.location.search to obtain the current query string and then build on that further. It won't include the hash fragments.
Thank you very much for your kind answer.
I will try to let you have a run on the form, the way a visitor would do it:
The site is a Job Meta-search machine, Google personal search, (no revenues for the moment otherwise I wouldn't bother anyone here)
You begin at: http://infoprofesionales.es/pageID_10075646.html
and introduce e.g "manager", enter, then redirect to result page:
chrome:
...INFOPROFES.ROOT.../pageID_results.html?cx=partner-pub-8427202809546935:rxxaj8en2yh&cof=FORID:10&ie=UTF-8&q=manger&sa=Buscar+en+60+Portales+(escriba+empleo+y+lugar+de+trabajo)
firefox:
...INFOPROFES.ROOT.../pageID_results.html?cx=partner-pub-8427202809546935%3Arxxaj8en2yh&cof=FORID%3A10&ie=UTF-8&q=manager&sa=Buscar+en+60+Portales+(escriba+empleo+y+lugar+de+trabajo)#1346
As you see FF ads the hashtag
I redirect because the result page offers three buttons which add by JavaScript the internal Google parameter (filter:time):
&as_qdr=w week or d day or h hour (brilliant way to filter results not compromising the Google code (which is not allowed)
So now I`ll come to an end and it is really simple:
These appendixes (&as_qdr=X) are added by the mentioned buttons to the end of the URL, and (which works in Chrome) cause a reload showing the desired filtered results.
BUT: Firefox won't work, why? because FF forces a double load (you can appreciate it lowering conn.speed) adding the second time an hash tag to the end of the url.And behind that tag: none of my parmeters takes any effect.
Chrome: no hash tag = WORKS (try and press my yellow filter links at the bottom of result site)
Firefox & IE hash tag = DOES NOT WORK (try and you will see my "&as_qdr=X" parameter behind the tag, but not igniting like in chrome)
I had to lower myself writing on the site "works only with Chrome" which is ridiculous - and I spent all kind of attempts from manipulating by java the string location, stop loading or whatever...
Never so much in vain.
It seems to lie on the hand: FF & IE load searchresults twice, first without tag then with ¿How forbid them loading twice (looks ugly anyhow).