Is there any additional DOM exposed that a bookmarklet can access to get a list of the URLs of all the tabs that are currently open in a browser? I have done some searching but have found very little documentation on what can be done in a bookmarklet which cannot be done in a normal web page - although having written some bookmarklets already it seems they have a bit more privileged status than a normal web page (although this seems to vary by browser).
I have done some searching but have found very little documentation on what can be done in a bookmarklet which cannot be done in a normal web page
That is because there is essentially none. For all practical purposes, running a bookmarklet is exactly the same as running script on the page. It is almost precisely equivalent to clicking a link on the page that has href="javascript:.."
although having written some bookmarklets already it seems they have a bit more privileged status than a normal web page (although this seems to vary by browser).
I've have also written and researched a lot about bookmarklets (check my SO history). I have found only 2 significant differences.
1.) You can use %s in the bookmark's URL in combination with a bookmark keyword for argument substitution via the URL bar.
2.) There is a weird hack in Chrome (which could easily get closed with some future update) which lets a bookmarklet open a URL in a new tab and then run code in that tab if and only if the user does CTRL+click on the bookmarklet. But that still doesn't let you do anything to tabs which are already open.
If you know others, let me know.
The only solution is to create a browser extension. If you can write a bookmarklet, it isn't much more complicated to write a very basic extension.
A bookmarklet is a javascript code that is being injected within a webpage;
If multiple tabs are available, the bookmarklet will be injected within the webpage of the current active tab.
The power of a bookmarklet is limitless, but it has effect only on 1 webpage, on the page that has been injected;
What you need here is a browser extension.
The extension gives you access to the browsers features;
Related
The idea is that when I open a certain site in Chrome using a desktop shortcut, I want a certain script to be automatically executed via the console. It is desirable that it starts executing when the page loads. This can be done? Through the properties of the shortcut or maybe a .bat file?
I want to make a shortcut for a quick reboot of the router, which, after opening the settings page, will log into the account and click on the necessary buttons to reboot. In manual mode, everything works, but I don’t know how to automate.
You can create your own chrome extension that does certain actions depending on what happens in the browser, it is actually quite easy to do and there are multiple guides out there on how to do it.
I will shamelessly plug my own guide on how to create one with react, be aware there are many other and probably better guides out there:
Guide
So there's an online quiz which uses flash, and my friend claims he has a script which pulls the answers from the flash app and displays them. I want to test this out, but I have a question:
How can I add or run this script to chrome so that this happens? In general, how can you run your javascript on a certain site on chrome? This concept interests me, and I didn't know it was possible to force sites to do stuff.
You can open the developers tools by pressing your F12 key or Ctrl+Shift+i. You can also right click on any element in the page and select "inspect element".
Once the developers tools are open, you can navigate to the right most tab called "console". There you can enter arbitrary JavaScript code to be executed on the currently open page.
Be careful what you paste into that console though! Someone might give you some malicious code to run. When you open the console while you browse Facebook, they actually display this warning:
Facebook is just an example. The same warning is applicable for any site.
It's quite a broad question. However. there are 3 main answers:
For one-time fiddling, you have the power of Dev Tools at your fingertips. You can run code in the context of the page, examine and debug its own code, make realtime modifications to the DOM etc.
To make a script execute every time you load some page, the traditionally used approach is Userscripts, a notion that came from Firefox. Google Chrome is able (or at least used used to be able) to handle them directly, but now most people use an extension, TamperMonkey, that runs userscripts for you.
Finally, if you need more powerful tools for interacting with your browser, you have Chrome Extensions. They are, basically, JavaScript scripts empowered with access to Chrome APIs. In this context, JS code injected into pages is called Content Scripts.
Well, I was scraping data from one of the website (purely in legal limits).
The situation is that the site has 5 questions on a page and answers to them.But the source code that I see by pressing Ctrl+u is different from the code that I see by Inspect element or firebug in Firefox.That means the site is changing the answers on page load to fool the people around as scrapers would normally grab the unmodified code.The correct answers are on the onLoad modified page.
What I want is to capture the source code that I see in Firebug or Inspect element (the modified code) instead of the code that I see on pressing Ctrl+U.
I used one of the scraping API but it is capturing that original Ctrl+U code.
Is there any solution?
In chrome, select root element (<html>) and right click -> Copy as HTML, paste wherever
[EDIT]
I suspect you are trying to scrape the data automatically, this obviously won't work, not sure how to do this otherwise. There are some headless web browsers that support JS (phantom js for example), they might do the trick. Also check out this super user post
I'ld suggest you to do a log of the html of your page before the onload happens. Which can be done using jquery.
Or plain classic debugging using "debugger" which will stop the exec of your webpage once the line where you put it is interpreted by the browser.
As a HTML5 game dev, I usually do advanced logging through the console, to know what does what and what's executed when. Although it may take some time, it allows you to have a good comprehension of what you've written and to ensure optimization (mostly in number of execs of some stuff) and to catch bugs that might not be obvious.
I have a problem with an specific web page. When I press on a link I got an application error (not http error etc but application level error).
But I had the developer tools and net console open and I saw that no requests are send to the server.
So I double clicked and selected view source and I saw that this error was part of the dynamically generated html but the html page seemed malformed.
It seemed to end like this:
<div id="theId"> You can not access page
</html>
The page as a whole seems ok though. When I use either Crome or Firefox I see the same thing.(IE is not an option as I don't have a windows pc available).
The view source does not allow me to "study" the page e.g. expand tags etc.
How can I debug something like this? Could it be for some reason that the browsers do not display the code correctly?
"View source" gives the HTML as it was sent by the server. What's generally way more useful is looking at the generated document structure.
In Chrome, you do this by opening developer tools (cmd-alt-i on Mac, ctrl-alt-i on Windows) and then look at the Elements tab (first tab).
In Firefox, you need to look at the "Inspector" tab.
In both Chrome and Firefox, you can right-click on any page element and select "inspect element". This brings up the tab with the document structure, with the selected element revealed. This is easier than hunting down the element you're interested in yourself.
Also, when hovering over an element in the document tree, both browsers highlight the element you're pointing at in the regular viewport.
There are two reasons why the final document structure (or at least, final up to that point in time) can differ from the HTML send by the server:
Javascript that modifies the document. For sites who make very heave use of Javascript (and especially the so-called single-page apps), the resulting document structure can be much different from the original HTML source. That just forms the basis for rendering the page. There's a lot done by Javascript afterwards.
Malformed HTML. In this case, all browsers try to make the best of what they have before them to generate a valid document structure.
To answer the question in your title, if your talking javascript yes and no if your talking html, then its a yes to accurate but no to complete.
Html can and is in a lot of web applications generated by the server side language, or even by javascript. So depending on what you have requested from the server the HTML could be far from complete.
Also when using things like html generation with languages like ruby or php, it can be very easy to end up generating bad/sucktacular html.
The story is a little different with javascript. By necessity of what it is, all of the source for javascript must be served up in some form in your browser. But do to the fact that things like jquery can be cached by your browser which means the code for it might not show when you open the developers console.
Then you have the issue of minifiers and obfuscation, and then obfuscators used on minified obfuscated code! Which can leave a horrible mess.
My guess is that their server generated some bad html which then broke their javascript,(resulting in the javascript not calling the server as you saw on the net log) which was then handled on your side of things with a error message displayed by the javascript that captured the error.
In Firefox, using the Web Developer Toolbar, there is a 'View Source' menu with a dropdown option to 'View Generated Source'. This outputs the complete html source as your inspector sees it, after being processed and updated by javascript. A very useful plug-in, and was my mainstay before the advent of Firebug.
As far as I'm aware, "view source" gives you whatever the webserver sent your web browser. Web browsers are often very forgiving when it comes to rendering syntactically incorrect HTML. If you're the one that develops this web page, you may want to take a closer look at what it's sending.
I'd like to be able to make the JavaScript I've got in a web page behave differently by doing something or setting something externally. So there'll be logic checking if(something) execute functionality one, else execute functionality two. I can think of three ways of doing this, but I don't like any of them enough to choose it. At least not unless I can see if there's another blindingly obvious way of doing it that's somehow escaping me at the moment.
Add a harmless query string to the URL (e.g. ?choose_functionality_one=true) and my logic can simply look in the page URL. The reason I don't like this is the case where my code is running inside a cross-domain iframe and I can't even access the page's URL (only the iframe's URL). Yes I could pass the query string to the iframe, but only if I have control over the parent page, and I don't.
Create a cookie in the domain of the page, and my logic can simply look for it in document.cookie. This could be done with a bookmarklet easily enough, and wouldn't suffer from the cross-domain problem, because I simply open a window/tab to the domain where my code is running and run the bookmarklet in that context. This is my front-runner choice at the moment.
Add something to the browser's useragent string and look for that in my logic. Pretty easy on Firefox via about:config, but is less easy with the other browsers, and downright difficult on the Mac. Also, on some browsers, once you've set a custom value, you lose the ability to have the UA get auto-updated when you get a browser update. Your UA's version info is stuck in time to where it was when you first custom'ed it.
Can anyone think of another way that via email/IM/phone I can say to someone "do this" and they'll see the page behave differently for troubleshooting purposes. For the general population who haven't done that though, it's running completely normally.
The simplest option seems to be to make a debug page on your site that will let the user turn the "debug" cookie on/off and then queue your regular site code off the existence of the cookie. I'd suggest making the debug cookie expire in a fairly short amount of time so people don't inadvertently leave it on.
This option has the advantages you are interested in (no user agent modification, works on all platforms, works with iframes) and I can see no disadvantages except that it wouldn't work if someone had cookies off, though a lot of the web won't work without cookies these days so that seems like something you could live with.
In addition, it's also the simplest for your users to use. You can just direct them to the right page on your site and all they have to do is click the desired button to turn it on or off. You can make the page very self explanatory which is certainly much easier than any of the other options.
OK, if you only control code and no HTML, then you could do either implement a keyboard shortcut key that would enable the debug mode by setting the cookie. The instructions could be something like this: put the keyboard focus in X and then press Ctrl-D.
Or, you could implement some special type of click (like a Ctrl-click on some object or in some page corner). In this case the instructions could be something like: Hold down the Ctrl-key and click on object X on the page.
Your JS code could implement either of those shortcuts. You could even put up a prompt (all with dynamically created HTML objects) when the special key/click was engaged to confirm turning the debug mode on or off.