how is it possible to easily obtain short form of XPATH through Inspector?
For example, if I try "Copy xpath" on web element I get pretty long response like this:
/html/body/div[6]/div[1]/div[1]/p[13]
Instead of this or similar:
//[#id='exeample_value']*
Since I need to cover a lot of these, do not want to loose time to shorten them manually. In older versions of Firefox I used plugins like Firebug and Firepath, but they seem not to be compatible with new FF versions (and FF Dev Edition).
The Firefox DevTools don't allow to copy relative XPaths yet (as of Firefox 58). Therefore I've filed bug 1410810 for it some time ago.
Related
Right now I'm using the latest ABC PDF version, and use the Gecko rendering engine. However, I notice that there are small differences between the way Firefox renders the HTML I'm adding to my PDF, and the way ABC PDF interprets the HTML. I was wondering if there is anything that can be done against this?
I'm asking about Firefox specifically because I thought that browser used the same Gecko rendering engine as ABCPDF did, so I thought it would be 100% the same.
Does anyone know about this? Couldn't find much about this on the internet, though I do admit that I find it hard to come up with the correct search terms.
By default ABCpdf will use the 'print' css media type whereas Firefox will be using 'screen', this can be changed by setting the media property.
var doc = new Doc()
doc.HtmlOptions.Media = MediaType.Screen
If the differences are more subtle it may be worth taking a look at engine configuration.
It is important to note the Gecko engine used in ABCpdf is independent from the engine used in any local Firefox installation, it should be assumed that it will be different in both version and configuration.
When attempting to click elements using a CSS selector, e.g
browser.find_element(:css, '.login').click
I am seeing different behaviours in different browsers. This is the behaviour I am seeing:
Chrome (35.0.1916.114) - works as expected
Firefox (24.0) - seems to ignore the command and move onto the next line of the test. Either that or it thinks it has clicked the element when it has not.
Safari (7.0.3 (9537.75.14) - complains that the element is not present. Interestingly, this one doesn't even seem to wait until the page has even loaded.
I have tried using a variety of web driver versions (2.42.0, 2.39.0, 2.33.0) and different browser versions with no success.
It turns out that my specific problem was that Firefox doesn't like targeting link elements inside lists, whilst chrome will do it fine. For example:
The following will not work in Firefox:
Browser.find_element(:css, '.list-item')
Whereas this will:
Browser.find_element(:css, '.list-item > a')
This may have been a unique problem for the site I was testing, but it is worth bearing in mind.
With the release of Firefox 25 we saw a huge improvement in their development tools. SO much so that I'm rather excited to try them out over Firebug.
However I can't see how to turn on Sass debugging, which is currently working in Firebug. I've looked in all the settings that are offered within the development settings.
I'm hoping I'm wrong and it is currently supported.
With Firefox 29 the support for Sass and LESS files was introduced.
Taken from https://hacks.mozilla.org/2014/02/live-editing-sass-and-less-in-the-firefox-developer-tools/
You have to right-click in the Rules section and activate Show original sources option:
Now CSS rule links will show the location in the original file, and
clicking these links will take you to the source in the Style Editor.
From there you can go on to the Styles Editor and edit your Sass/LESS file. Functionality needs Source Maps enabled!
The best suitable way to debug Sass in Firefox seems to be FireSass.
https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/
It looks like IE7 doesn't reload the latest version of my stylesheet each time I upload a new version on the server.
This is annoying as I am debugging my .css file to make it work on IE...
Tried to empty the browser cache but still not working.
Thanks for your help.
Ctrl-F5 - forcible way to reload in IE
Include your version number in the file name. myfile_v1234.css
When testing, every time you do an update you can just wite "stylesheet.css?r=98123"
As long as the query string is different, it'll be downloaded again.
If you need, you can use javascript to append Math.random(), to get the random number. Not required on production though, when updates would be stable.
2 Questions:
Does IE eventually load with the newer stylesheet?
How are you saving the changes to the server (SSH, Web Interface, etc.)?
I ask because I ran into an issue with a web-based file management system a while back where one browser would show the CSS just fine, the other wouldn't, and we noticed the issue of which browser played nicely depended on which browser we used to upload the CSS.
The reason turned out to be that IE gave the CSS file a different MIME type than Firefox. If you continue to notice the issue even when you've cleared the cache, check the MIME type of the file using Firefox by going to Tools > Page Info.
Also, if it is simply a caching issue, consider turning caching off in IE. I believe this should be an Advanced Option under Internet Options.
Also, you may want to try creating a special developer environment for IE (if it comes down to it.) Perhaps have another machine with IE7 and no caching and any other features turned off (A kiosk mode, perhaps), and then previewing the page on that machine.
Thanks to you all!
I did manage to solve my problem with the "stupid" Ctrl+F5, and by changing the Internet Parameters of Windows to reload content every new visit.
Back in the earlier days of the internet I remember that in certain browsers, every time you downloaded an image or a file, the URL of where that file was downloaded from would be written into that file's properties (I guess the summary tab?). I think Netscape v2 did this if I remember correctly.
I really miss that kind of functionality as every once in a while I'll run into a neat little program stored somewhere in the depths of my hard drive and wonder where I got it from originally.
I googled around but I'm not quite sure what terms to use to describe what I'm looking for. So I'm wondering if anyone knows of a Firefox plug-in or something similar that would do this?
If you use the DownThemAll! extension for Firefox, you can tell it to prepend the URL of the site to the downloaded file name...
thus you end up with files like:
download.com_utils_compression_ABCD32.exe
It also works really well when you want to download/queue a bunch of files.
You download http://example.com/foo to ~/Desktop/foo, and you want to see the originating URL in the properties of the local file foo?
Back when I used OS X, I remember Safari used to record the original URL in the resource fork of the downloaded file. Can't remember what the named fork is, well, named, but it'll show up in the properties panel from Finder. Since it's there, Spotlight will probably index it, too, but I haven't used OS X since 10.3.
If you use Opera, and haven't cleared the file out from your download manager, select the download and it'll show the original URL that the file is from in the properties pane.
Is this what you want? If so... well, I don't know of a similar Firefox extension, but it'll clarify the question.
For the IE Browser I use the hell out of Fidler to look at all traffic going across the wire.
For FireFox, you can use the FireBug plugin. There is a "Net" tab that will show you request information that is going across the wire.
Most of the time you can use one of these tools to see what URL was requested in order to start a download. You can also view all the get and post information that might need to be sent in order to have your request succeed.
Fidler is here: http://www.fiddlertool.com/fiddler/
FireBug is here: https://addons.mozilla.org/en-US/firefox/addon/1843
Best of Luck!