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

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.

Related

How to use Codemirror codefolding without "["?

I would like to use Codemirror codefolding to fold just { and } as well as comments. The only problem I am having is it also codefolds the brackets [ and ]. The square brackets are almost always part of one line statements and I do not wish to use codefolding for them. How can I prevent that?
In codemirror/addon/fold/brace-fold.js I tried commenting out these lines:
if (startCh == null) {
startToken = "[", endToken = "]";
startCh = findOpening("[");
}
but that still does not prevent codefolding for square brackets. Also, any ideas what addon/fold/indent-fold.js does? I am not sure whether I should include that file.
N.B.
I am using Codefolding for both JavaScript and PHP modes.
EDIT
Here's a demonstration of Codemirror codefolding.
The OP code is just fine.
According to comments the problem was coming from a cached version of the file, making the modification seem like they are not working.
To prevent this kind of problem in the futur, note that hitting F5 will not clear cache. You need to use ctrl+F5. Another good option I use is in the developer tools (I use Chrome but it is certainly there in other browsers too), you can set the browser to clear cache whenever the devtools is open. Since the tab is almost always open when testing your website, this makes cache problems never happen...

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.

Javascript location.replace bug in Opera

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?

Why is Firebug hitting non-existent break points?

I've been using Firebug to debug some javascript I have on one of my pages. Recently it has started hitting non-existent "break points" at seemingly random spots in my javascript. It seems like most of these points are in third party libraries like jQuery, but it also stops on custom javascript.
I'm not seeing any errors at these lines and I definitely don't have break points there. Can anyone think of why Firebug would be stopping here? It's getting to the point where I have to hit the "Continue" button about 20 times to get the page to finish Javascript execution...
I had this problem and fixed it like so:
Uninstall firebug in the firefox add-ons manager
Close firefox
rm -rf profile_folder/firebug
Delete all firebug-related lines from profile_folder/prefs.js
Reinstall firebug
Hope this helps!
There is nothing wrong with firefox, this is happening because you might have enabled auto breakpoints. Check here http://getfirebug.com/wiki/index.php/Script_Panel for more details about what i am talking about. Disable them on console and script panel and everything will be solved.
This question is old, but it is also the top result for searches: like firebug random breakpoints.
In my experience, assuming this is not due to break on exception or other settings, every time this happens to me there is some collision with jQuery, or another library. Sometimes even name spacing does not keep you safe, and this is very hard to debug.
Most recently I had a function named: name_space1.nestedns.focusCursor(). Something was messing with my focusCursor function.. didn’t figure out what, just changed the name.
Farther in the past I had a function or var named ns.companyabreviationToolTip... and there was collision and breaking on this as well. Changed ToolTip to something obscure, and everything was happy. Maybe firebug has a secret break on collision setting. If this is a bug, I hope it does not get fixed… it seems useful.

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