I often would like to compare a new change with the original. To do this, I open two browser tabs of the same page, make a change, then reload one of the tabs to compare. With Browsersync enabled, this becomes impossible because both tabs automatically reload.
How can I disable Browsersync for a particular tab to prevent this from happening? I'm looking for a way to do this from the Javascript console, not having to stop/reload my watcher.
The Browsersync API has a pause() method, but I can't see a way to access this from an actual running Browsersync instance. There is a window.___browserSync___ object accessible, so there must be some way to achieve this.
The command should be:
window.___browserSync___.socket.disconnect();
If the ___browserSync___ object isn't available for some reason from the console try doing this in a fresh tab.
Related
I am working with third-party code (npm package) which uses opn (another npm package) to open default user browser during authorization. Instead of this, I want to open a new tab in the existing browser by sending some kind of request to the frontend. As I don't want to rewrite/copy all third-party code to actually change only one line inside, do you have any ideas how can I achieve this other way?
Will it be possible to detect action like opening browser and send the request to frontend instead? I know that opn spawns node child process.
Do you know if I can somehow efficiently change one of the third party code files so other files from this package will use my code instead? I could edit code inside node_modules to fulfil my requirements and never update this npm package but this sounds like a terrible idea.
If you want to open a new tab you should use Chrome DevTools Protocol.
You can read more here
https://github.com/cyrus-and/chrome-remote-interface
I guess you can't catch an 'open browser' event. But it should be possible to ask periodicaly the browser by something like 'chrome-remote-interface' npm package.
When I use
budo index_editor_java_02.js --open --live
every time I see same thing ,even I changed
index_editor_java_02.js
nothing happen and I see already what was in the browser at
http://192.168.5.10:9966/
before.
so How should I changed the js file makes changes in browser
same thing same port.non attention to what is in javascript file.
I think in first loading something registered in system so for times after that it could not change that.but which system .where and how we could change it is my question.
Regards
I write an application using node-webkit. I want to use HTTP for network communication between computers, running my app. Can I change current page without server restart if server was started from the page?
I thought about child process, but I want to shutdown the server with my application. I don't want to use special network request to the server to close it.
Can I change current page without server restart?
Can I save child process object while page changing?
Do you know other way to do this?
P.S. Sorry for my english.
I found the answer in the node-webkit documentation.
In node-webkit, you can basically do the same thing by using
window.location, you can install it in the onclick event of a link and
node-webkit will navigate to a new page when user clicks it. But by
doing this you would lose everything in window context, you can save
everything in cookies like old web pages, or you can save things in
the global variable, which resides in Node.js's context and will live
through your app.
I'm wondering, is it even possible to treat the request for the Xul Browser component to open a new window? I tried changing the window.open function, but looks like it's never called.
All links that open in a new window are not opening in my application.
I found this page on the subject, but the provided solution is showing no different behavior.
Any hint on this?
(by the way, I'm developing a stand alone application, not a Firefox's extension)
I'm assuming you are in a XULRunner application, and that you are trying to load a chrome URL from a non-chrome source in a browser (e.g. HTTP or local file). While enabling UniversalXPConnect and UniversalBrowserWrite can be helpful, they are also a security risk (since any arbitrary script on the web could use them), so they tend to be disabled in browsers (for example, running that line in Firebug will give you an exception):
>>> netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect UniversalBrowserWrite");
Error: A script from "http://stackoverflow.com" was denied UniversalXPConnect UniversalBrowserWrite privileges.
How about you try using codebase security principals and see if that makes a difference? (http://www.mozilla.org/projects/security/components/signed-scripts.html#codebase). For me in Firebug it does allow me to get the additional permissions after I OK it with a big, nasty looking dialog), but still doesn't allow me to open a Chrome URL with window.open. The next step is probably to try changing your conf file to use contentaccessible so that the relevant parts of your content are accessible (see https://developer.mozilla.org/en/Chrome_Registration#contentaccessible).
To avoid the nasty message when elevating permissions, you could try setting permissions for the right files automatically as described at http://forums.mozillazine.org/viewtopic.php?f=38&t=1769555.
Also, make sure you check the browser type (https://developer.mozilla.org/en/XUL/Attribute/browser.type). If the browser type is not chrome, then it might be worth trying making it chrome and seeing if that makes a difference.
If any of my assumptions are wrong get back to me and I will try something else.
does normal js not work?
window.open(url,windowname,flags);
There are two ways that I know of.
The first is to set the browser.chromeURL preference to a chrome URL that contains a <browser type="content-primary">. The page that the content window tried to open will load into the given browser.
The second is to set the property window.browserDOMWindow with an object that you define to implement the nsIBrowserDOMWindow interface. This allows you to divert the open call into a tab, if you are using a tabbed interface. Note: the tabbed browsing preferences must be set to allow windows to be diverted into tabs, otherwise XULrunner will fall back on browser.chromeURL.
Is there any method to tell from javascript if the browser has "enhanced security configuration" enabled?
I keep running into problems with certain controls not working from within dynamically loaded content. This only happens with browsers running on Windows Server 2003/2008 systems - even when I add the server to the "trusted" zone.
Maybe somebody has already develoepd a method for accomplishing this task?
Thanks in advance
Instead of testing for IE ESC directly, we can test for its effects.
I found that with ESC enabled the onclick events of dynamically added content would not fire.
So I am testing those events directly.
var IEESCEnabled = true;
var testButton = $("<button style=\"display: none;\" onclick=\"IEESCEnabled = false; alert('No problems here.');\">Test IE ESC</button>");
testButton.click();
if (IEESCEnabled) {
alert("We have a problem.");
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
In my application a test like this forwards the user to a page explaining their issue. It is accompanied by a noscript element to check that they have JavaScript running at all.
I don't think it's possible, and if it still is, than that's a bug that might sooner or later be fixed.
One of the main points of this "extra security" was for the client to have it but not to be detected by the servers, thus leaving them no way to know when to try to circumvent it and when not.
Isn't javascript disabled when using enhanced security configuration?
Then if you only want to display a message to the user, simply display a message in normal html and hide it with javascript so only users without javascript will see it. If you need to handle it on the server side (e.g. outputting a differerent version of your website) simply include javascript to redirect users to your javascript enabled version. Users without javascript will remain on the non-js page.
If only scriptable activex are disabled, the same method applies, simply insert a activeX and try to "script" it, if it fails you can redirect, show a message etc.
The above of course doesn't detect enhanced security configuration per se, but the symptons that occur when it is enabled. So it probably wouldn't be able to distinguish between users with using enhanced security configuration and users that simply have JS/ActiveX disabled or use a Browser that doesn't support scripting in the first place.
I think you can look for SV1 in the user agent string.