Despite extensive Google search I haven't been able to find what I was looking for, so I'm hoping experienced SO users will have an answer.
I am looking for a Firefox or Chrome plugin that can automatically display elements' id attribute value inside an overlay on top of the actual elements. For instance:
The idea is to be able to have a quick snapshot of what id attributes are used within a page and where, instead of having to go through the entire page manually with tools such as Firebug or Firefox/Chrome's DOM inspectors (which only allow you to see elements one by one, not have a full picture).
Does anybody know a Firefox / Chrome plugin that can do that?
The "Web Developer" extension for Firefox / Chrome includes this feature. The option can be toggled by clicking on "Information -> Display Anchors".
https://addons.mozilla.org/en-US/firefox/addon/web-developer/
https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm
In Firefox
In Chrome
Result
Instead of installing an extra extension, you could also enter $$('[id]') in the console, which results in a list of all elements with an "id" attribute.
Related
I have a scraping script written in Ruby which uses Selenium, Watir and ChromeDriver, all is working just fine with a Chrome browser window, but trying to run in headless mode just hits;
Selenium::WebDriver::Error::UnknownError: unknown error: Element <input id="desired_element" type="checkbox" name="desired_element" checked="checked"> is not clickable at point (660, 594). Other element would receive the click: <html lang="en">...</html>
I'm using Watir 6.8 and latest Chromedriver 2.33.
Any ideas whats n=behind the different behavior of the page when in headless vs non headless, and how I can deal with this?
The error message is telling you what the problem is when it says "Other element would receive the click:"
This means some other element on the screen is covering the checkbox you are trying to interact with. Likely this is caused by whatever the default browser size in headless mode being different than the default size of your browser when it is run non-headless, resulting in a different arrangement of elements
We can verify if this is the case by asking the size of the window in both headless and normal modes and seeing if the resulting values are the same.
size = browser.window.size
puts "The browser window is #{size.width} wide by #{size.height} high"
There are a few potential ways to solve this:
Specify or alter the browser 'window' size. for example
browser.window.resize_to 1024, 768
I prefer this, and normally have a command such as that to set the
browser size right after it is initialized. Set either to the
minimum supported size for your site, or the minimum recommended
size
Use another means to 'click' on the checkbox, such as sending a space at it
#browser.checkbox(name: "desired_element").send_keys " "
I do not prefer this as it doesn't really solve the source of the problem and you may experience other similar issues interacting with other elements on the site as your script progresses.
The reason for this kind of error is that web page doesn't load well enough to locate the element. As you have mentioned that the tests previously passed when you had headless true such issues might be because of .click() , please try replacing .click with .send_keys
.send_keys(selenium.webdriver.common.keys.Keys.SPACE)
When you use .send_keys() you might hit one more issue if it is failing to find elements, for solving this you will have to find the elements
elements = driver.find_element_by_tag_name("html")
elements.send_keys(Keys.SPACE)
Hope this helps you.
I'm automating a web page which contains several nested iframes. This makes it hard for me to find the proper locator for the elements. I use firebug, the f12 tools ... to get xpath etc. but I miss something here, the iframe id.
Does someone know a tool where I can point on an element on the web page, and get the xpath and the iframe id?
THX
Firebug displays the iframes containing the inspected element within its ancestor path:
By clicking on the buttons within the ancestor path you can jump to the related iframe.
To get the XPath for an iframe right-click on it within the HTML panel and choose Copy Minimal XPath or Copy XPath from the context menu.
https://developer.chrome.com/extensions/optionsV2 tells me that I should be using options_ui in my manifest, rather than options_page, and recommends I start upgrading immediately.
However, I can't find any way to actually debug the script run by my options page when I use options_ui—the Options popup is in an tag, and the developer tools don't show me the source, or even the HTML content.
For now, I just comment out options_ui and let options_page take effect when I need to debug. I'm guessing that setting "options_ui": {"open_in_tab": true,...} would have the same effect, but it would be really nice to figure out how to actually debug the script when it's running the new way.
Auspex,
Teepeemm's comment is correct.
Other way, you can launch your options page from other tab using its full URL
like,
chrome-extension://{your extension id here}/{your options page path here, from the extension root}
e.g. say my extension id aaabbbcccdddeeefffggg, and say, my options page is located (from extension root) at app/html/options.html; then i can load up below URL in a new tab ---
chrome-extension://aaabbbcccdddeeefffggg/app/html/options.html
Now here, in this tab; you can do your regular debugging around HTML and javascript.
I hope this suffices your debugging requirement for 'new options UI' for chrome.
Teepeemm's comment is correct.
It's as simple as right-clicking inside the options page modal and selecting "Inspect element" - it will open the correct Dev Tools.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I would like to dump all css key/value pairs for an html tag.
In particular, I would like to learn the css properties for <audio> tag, so I can try to customize the look.
document.getElementById('myaudio').style returns a CSSStyleDeclaration object but length returns 0 and I cannot figure out to iterate over the key/value pairs.
Thank you
Try Firebug for firefox. It allows you to view the CSS and properties of any element on a webpage and allows in-page editing so you can customise it on the fly until you are happy without having to create hard and fast changes
You can't iterate over the keys in the style object. It's simply impossible.
The best answer is what Chris said. Use Firebug in Firefox, or similar tools in the other browsers, which can do the work for you and tell you exactly what CSS properties apply to the element.
(Make sure that you tell the tool to show you "user agent styles", not just styles you've added, so you can see what styles the browser applies automatically.)