Javascript location.replace bug in Opera - javascript

I'm am doing a JS location.replace in Opera. There is a known bug that the location does not get replaced but updated when only the location.hash changes (see http://my.opera.com/community/forums/topic.dml?id=568931).
I was trying to do the following workaround:
var url = location.href.split("#")[0];
if (window.opera) {
window.history.back();
}
location.replace(url + '#' + newhash);
Unfortunately that does not seem work. Before I start experimenting with setTimeout, I wanted to check if maybe someone has a better idea.

I think the best workaround for this is to not work around it at all.
Reasoning: firstly, the script running in this page should be terminated if I use the back button, or history.back() is called. Hence, in your workaround above the script will (or should) actually stop running before the location.replace() call. We can not remember that you wanted to call location.replace() and do it on the page you've gone back to, because that would be a script injection security issue.
Secondly, even if this workaround worked I would very much recommend not using it. The reason is that Opera will eventually fix its bug. If an end user used a fixed Opera version and a page running your script, each click on one of your links would remove one entry from that user's browsing history..
For a proper solution, you could investigate history.replaceState() - a new method specified in HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-replacestate

Can you clarify a bit? I took the example from the forum link you posted and uploaded it here: http://people.opera.com/miket/tmp/replace.html. In Opera 11.61/Mac, it appears to work as expected.
Are you seeing something different? Can you explain your problem in more detail?

Related

Is there any way to prevent `window.location.href` from being changed?

I'm trying to prevent a mangled & uglified 3rd-party javascript from changing location.href unnecessarily. Object.freeze seems to be a clean and preferable solution, but it does not work :/
The solution provided here seems to be ineffective.
Object.freeze(window.location)
window.location.href = 'somewhere'
// still jumped to 'somewhere'... :(
An alternative idea is using beforeunload event of window. But actually I don't think it's a good idea... since it still gives a confirm dialog when the unnecessary jump happens.
I'm currently using Chrome 100 on Windows 10 with disable-web-security flag.

Javascript is acting buggy on Chrome

It's a little hard to describe as I have very little knowledge about Javascript, but it seems to be causing some issues with my Chrome browser. The best way I can say it is that a lot of things that use Javascript are broken. For example, when I visit a Wikipedia page and try to click 'show' on a nav-box, it takes me to the top of the page instead of opening the box. These things still work on IE, so I know this issue at least limited to Chrome. I don't know how this issue started. What exactly is going on here, and how can I fix it?
It's been resolved. I did a full reinstallation of Chrome.

fb:loggin-button gets stuck [duplicate]

I am having problems getting Facebook login to work correctly in IE. The problem is intermittent. Usually, when it makes the call to FB.login, the popup appears but stays on an empty white page, XD proxy, and never runs the callback. Occasionally, the callback will run, but the window will not close - I think this may be the first time I try it after rebooting my machine (closing and opening the browser does not have the same effect).
You can see this problem on www.runescape.com/, yet with the same code on www.waroflegends.com/, the login seems to work correctly.
I have searched and found a lot of talk on the XD Proxy topic, but none of the solutions seem to work for me. I have tried adding a custom channel url and making sure the fb div is the first child of the body to no effect.
I've been experiencing the same issue in IE9, and it seemed to stem from upgrading to Flash Player 10. I'd lost hope in trying to fix it since finding an open bug at Facebook covering it. But Henson has posted an answer that fixed it for me. In the JavaScript in my site master I removed the lines
FB.UIServer.setLoadedNode = function (a, b) {
//HACK: http://bugs.developers.facebook.net/show_bug.cgi?id=20168
FB.UIServer._loadedNodes[a.id] = b;
};
and now it works. (N.B. I have not checked to see if the IE8 issue those lines were intended to overcome returns.) If that's not it take a look at some of the answers suggested in FB.login dialog does not close on Google Chrome
Try this right after FB.init:
if($.browser.msie || $.browser.opera) { // yes, this is jQuery :)
FB.XD._transport = 'fragment';
FB.XD.Fragment._channelUrl = yourChannelUrl;
}

Why is this 'href' value not working in Opera?

I have the following:
Test
When run in Chrome, it functions as expected and turns the page red. However, in Opera I get:
[object Object]
Closer inspection reveals that Opera thinks that javascript:Query('body')... is some kind of URL. What am I doing wrong? Doesn't Opera recognize javascript: links in the href attribute?
jsFiddle: http://jsfiddle.net/9CZZL/
Edit: seems to be a Firefox problem too...
The issue is that the return value of jQuery('body').css('backgroundColor','red') is an object, which some browsers interpret as the new content for the web page. To fix this, you can use the JavaScript void operator to turn it into undefined, which FF and Opera (and potentially others) will handle as you intended. You will notice that this issue is also described on that page, since it's the premier use-case of the void operator (other than code golf where void 0 is less characters than undefined).
Test
This should give the intended result: http://jsfiddle.net/9CZZL/13/
It should be noted that handling clicks this way is considered bad practice. Instead, using event handlers in JavaScript is recommended. This helps separate the different layers of your web app, which in turn will make debugging in the future easier.
I just did a google search and no, apparently Opera does not recognise "javascript:" href values. You would have to implement an onClick or similar solution.
Does it in Firefox too.... not quite sure why. But I never liked putting JavaScript right in the URL... you could try putting it in the onclick event or pull the whole thing out and separate it:
http://jsfiddle.net/mnbayazit/6d5An/
These all work as href values for me in Opera 10.1:
javascript:void(0)
javascript:alert("Hello")
javascript:window.location.href = 'http://www.google.com'
Your snippet does not though.
A viable work around is:
Test
Or even:
Test
...since that seems to work.

Sometimes FCKeditor doesn't load in Firefox

I am unable to replicate the problem when I want to but it seems like every now and then, my site using FCKeditor will load the interface but not the content (Clicking the buttons don't do anything). No javascript errors show and once it starts doing it, it usually is tough to get back to normal. The way I found to work best is to click the refresh button multiple times in a row, then the FCKeditor loads correctly. I have only seen this in Firefox
Has anyone else run into this problem or know a solution. It is a little annoying for me but I am afraid my client would be really confused
I have experienced the phenomenon you describe in FCKEditor's successor, CKEditor. Somehow, the IFRAME that contains the WYSIWYG content doesn't get loaded. What always helps is switching to source code view and back, but that's no solution.
I have seen the problem described on the Internet but with no solution.
Caching is not the problem, I think. Sometimes, if you press "reload" 20 times, it will break at the 21th time, and work again on the 22nd time.
What minimized the number of occurrences for me was to activate the thingy to the editor's bottom that shows the element path (body > p > span, I forgot it's name). I don't now why but since I turned it on, it very rarely breaks any more.
I have had this problem. I solved it by pre-loading FCKeditor in a hidden iframe during the login process so that when it got to the pages where it was used it was already in the cache.
i would strongly advise to upgrade to CKEditor which can not only be spelled out verbally without offending anyone, but also optimizes the loading time to minimal. I find it much more responsive than his F- friend.
I encountered this problem with firefox (not reproducible) and chrome (reproducible).
The solution that worked quite well in both cases was to wait for some milliseconds before initializing CKE :
setTimeout(function() {textarea.ckeditor({customConfig : 'custom/schnonfig.js'})} , 100);

Categories

Resources