I have a script that writes an iFrame which loads a page. I created a JSFiddle to make things clear:
link JSFiddle loading CNN in a frame
This loads CNN in a frame. If you scroll down in the frame to the news and click on the new articles and then 'back' there is some strange behavior in both Safari and Google Chrome: clicking 'back' doesn't take the iframe 'back', it takes the entire parent frame 'back'. How can I prevent this from happening?
Also strange is that fact that this doesn't always happen. Try it out for yourself, click at least 5-10 links and you'll see that the fiddle will reset itself every now and then. And that shouldn't happen...
This is behavior that only seems to happen in Safari en Chrome, Opera and IE don't seem to have this problem...
Browser registers history events when you click different URLS, since iframe is part of the page u are on it will register the click inside the iframe as a history event of the parent page. Different browsers may have slightly diferent behavior - I expect FF and Chrome be one way and IE behave slightly different. However testing your example both Chrome and IE worked exactly the same and pretty much as expected.
So to clarify:
Loading JSFiddle is a historical event as far as browser is concerned.
Clicking the button to create and load an Iframe is NOT a historical event.
Clicking a URL link within the Iframe window is a historical event.
At this point u have 2 states that the browser remembers and you can go back and forth in history between them.
Related
I dont know if this is a bug that was introduced on latest version of chrome because it does not happen on any older version of chrome nor on any version of Firefox. Maybe it's a feature or a bug, but I still need a way to fix it but after trying from 2 hours, no luck.
The problem: I have a page with a button and an iframe inside. When I click the button I change the iframe SRC. It works fine. However, if after clicking the button I click the BACK button of chrome browser, it makes the iframe reload the SRC that was assigned.
When I click the BACK button of chrome, it should not mess with iframe history. This problem just started happening now, only on latest version of chrome.
Any way I can fix this using the history object, I mean, preventing iframe navigation to affect the top window history?
http://nycweb.io/test.html
Its html is
click
In chrome's console, if you do
document.getElementsByTagName('a')[0].click()
It will open a new page of google.com. Surprisingly, in Safari, this doesn't work. I searched around and found this page saying there is a bug with Mobile Safari which prevents the click event from being triggered. Also it lists some workarounds. I was hoping it would help when I started reading it, but it actually makes me more confused.
First of all, it says the bug only happens with Mobile Safari, but anyone with a Macbook can test from the link above that it doesn't work with Safari either; second of all, it says it only happens with "elements that aren't typically interative", and the workaround includes adding "href" to <a> to make it interative. But my test above shows that it doesn't work with <a> at all, no matter it has href or not.
The actual problem I am trying to solve is this page "http://fbnydob.applinzi.com/test.php", where you can see a warning message pushed by the Hosting company, which can only be prevented by click the little 'x'. I was trying to click it programmatically but it is an <a> even without href, so my program fails to work on Apple devices and my users keep seeing this unpleasant message.
Any workaround for this that actually works?
Could you try firing the click event?
document.getElementsByTagName('a')[0].fire('click')
This will call the click handler and close the popup window.
I have an element and a link. I want mouse interaction with the first element to behave exactly like it was the link. This means that
left-clicking should navigate to the href
ctrl+clicking should open in a new foreground tab
middle-clicking should open in a new background tab
shift+clicking should open in a new window.
See this fiddle for an example with a table row.
This works perfectly in Chrome but not in Firefox. This question is similar but doesn't ask about the non-left-click behavior and also doesn't work in Firefox.
Note that the MouseEvent works fine in Firefox for left-clicking (and should be supported since MDN documents it) since you can see the console.log. By the way, you can't even catch middle-click click events, but you can listen for mouseup (or mousedown, but that would be silly).
It's possible to simulate the first two behaviors instead of just dispatching the event to the link and I don't care so much about the shift+click case, but middle-click doesn't work in Firefox.
I came across an interesting bug feature tonight when writing a handler for window.onresize in Chrome (the latest version 6.0.472.55). First open two tabs, then in the first tab open this jsFiddle.
Resize the window at will and the dialog box works as expected. Now, try switching to the 2nd tab -_-. Why is resize firing when the tab is changed? Could someone provide insight/more details if I need to file a bug?
The bug has been filed with Google. For the time being, I've just ignored it since my actual onresize handler doesn't display alert boxes.
Well how about that? Sounds like a bug. I would guess that onresize is listened-for by a combination of behaviors, probably new data about the page size that, for whatever reason, is coming in when a tab is focused.
In the version I use on Windows, 5.0.375.127, it doesn't happen, but if I actually resize the window, the resize event fires twice.
Knowing it's there, you can take a step to defeat it (that Google ought to do for you eventually). Wrap an if statement around your handler that checks for an actual change in the clientHeight or clientWidth if you need something to happen only if the event (as we understand it) actually occurs.
From the bug report:
When using Dev Tools in splitview and switching to a Tab without Dev
Tools opened in split, the resize-Event will be fired.
So, if the next Tab doesn't have the same window size, resize() will
be fired.
Without a working knowledge of how Chrome handles tab switching and page rendering, my guess is as good (or bad, depending how you look at it) as the next guy's. I would guess that rerendering the page, or reloading the already rendered page if it caches it, triggers the onresize event. This is what happens when the tab is switched. Following my theory, I would guess that Chrome doesn't trigger the resize event on initial page view because it has been designed not to. But again, as I don't know how Chrome handles tab switching internally, this is just speculation (food for thought).
So I'm creating some HTML using javascript based on where the user clicks on the page. On page load the script replaces an empty div with a ul and some data. The user clicks on that data to receive more and so on. Now when the user navigates off the page and then hits the back button to go back to the page, IE displays a blank page with the replaced divs, in all other browsers, FF, Opera, Safari, the page either reloads to the initial ul or goes back to the last state with the dynamic data in it.
Anyone have an idea as to what might be happening here? Any help is appreciated.
It sounds like you need to manage the history and state of your page. Check our Brad Neuberg's Really Simple History.
The behaviour of onload events when navigating backwards and forwards is not standard cross browser. As a general rule, I have found that when you click back, onload events tend not to work as the browser is loading it from cache rather than re-requesting the page. What you can try is using the dom ready event rather than window load.
Trull's answer is along the right lines. Opera and later Firefox(>1.5) do not consider loading a page from the cache as requiring to trigger an onload event as the complete DOM state is also cached.
This is trivial to standardise across browsers, as Opera and Firefox do not exhibit this behaviour if you define a window.onunload event. See http://developer.mozilla.org/en/Using_Firefox_1.5_caching