As per usual when making automated tests I use "Inspect"(CTRL+SHIFT+I) in Chrome to find element by xpath, id, CSS selector etc.
For example:
//li/a[contains(text(), "Products")]
Above is an xpath from this page. In previous versions of Chrome in "DevTools"/"Elements" after pressing CTRL+F to open the "Find" option and pasting this xpath element is highlighted in DevTools window. In new version of chrome it is not highlighted, the usual "1/1" results is displayed in far right of the "Find" tab.
I've search the internet and Chrome Settings but to no avail.The yellow highlight is time saver and I know for certain that I am using the right element.
Edit: Fixed with Chrome version 84.0.4147.105
Thank you for updates, suggestions, workarounds etc.
Yes, In recent updates of Chrome 84, Find feature is buggy. 3 issues have been reported and those are in unconfirmed status as of now (while writing this answer). You can follow them on below links for more details -
An element in the elements tab is not highlighted if it is only one in the DOM
"Find" feature not working on "Elements" tab
Finding element/xpath wont direct to the object
Update
Elements search does not resolveNode (highlight text, etc) on first search result
Has been fixed and it is part of Version 84.0.4147.105 (Official Build) (64-bit). You just need to update and relaunch the chrome. The issues mentioned above are marked as duplicate to this issue.
The major issue is with DevTools within Google Chrome 84.0 which doesn't highlights the first matched element.
Incase, the locator finds a single match, the search result does show 1 of 1 but the WebElement is not highlighted within the DOM Tree
As an example, the Search Box within the Google Home Page can be identified uniquely using the css-selector:
[name='q']
or using the xpath:
//*[#name='q']
But google-chrome-devtools within Google Chrome 84.0, does finds the element and shows 1 of 1 but the element is not highlighted.
However, if there are multiple element matching to the Locator Strategy, leaving out the first matched element, the other elements are highlighted.
Bug in Chrome 84
This issue was raised in the Platform>DevTools queue through Issue 1108311: The first matched element in the Elements panel is not getting highlighted as per the cssSelector and had been merged into Issue 1103316: Elements search does not resolveNode (highlight text, etc) on first search result where we are actively tracking the issue.
Solution
As per #bugdroid the main issue was caused because a check to ensure the search results were valid did not account for the case where the index was 0, so all highlight results of index 0 (index 1 to the user) were no longer highlighted.
The fix for this issue is Merge-Approved in:
Chrome version 84.0 later then Version 84.0.4147.89.
Chrome version 85.0.
Chrome Canary version 86.0.4201.0.
Alternate Solution
For alternate solutions using the current google-chrome Version 84.0.4147.89 you can find a detailed discussion in Why XPath does not highlighted the yellow mark in Chrome84?
Also as a workaround you can try using chro path extension, where you can paste your written xpath in search box and see element getting highlighted in browser.
Additionally you will be able to get automatic locators formed by chropath itself
I have also faced a similar issue where first matched xpath is not visible in chrome ( mac os mojave).
As a workaround, I am using the chrome console for exactly locating the xpath element.
Steps :
Open developer tools
Click on Console tab
type command as : $x("xpath") and press enter.
Find the below image link for reference.
dev console
Another option is to go to console section and evaluate your xpath like this $x("yourXpath") and hit enter. In the case of google search button woulb be like this: $x("//*[#name='q']") then you hit enter and expand the structure that appears below and if you hover with the mouse, the element is going to be highlighted.
I had the same issue, but the thing is .....
you should after you position your cursor to a particular text or control or button(etc) that you wish to inspect, then right click and choose Inspect element, then in the area where you see the code...I mean in Element tab of the opened DevTools, keeping your cursor on the text of the code at any place, then click Ctrl+F and it will open a search field
and then you type an absolute or relative xpath of your element that you would like to find and when the path is correct, your text will be highlighted with yellow.
Surprisingly, if I just move my cursor out of element tab and still do Ctrl+F, the search field will open, but the element is not highlighted in yellow as before
I had started using firefox!
It is being fixed by chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=1103316.
Should be out soon.
Related
Debugging a page where I see that there are two calls made to the page, one is the initial call and one is made when the first has been recieved and the browser parses the document. I am however having trouble finding the source of the second call. I have built the javascript i dev mode so I have sourcemaps but the call seems to be originating from the html code itself. Looking in the Network tab of devtools I see this
in Chrome and this
in Firefox
Firefox seems to identify the Initiator as image but no more details as to what image.
What should I look for in the code to find the source of the call? Is there something else I can do to get more details of where the call is made from?
Update:
Clicking the initator item in Chrome marks the first Doctype line in the document
That the request is recognized as an image is an indication for either an <img> HTML element or a url() CSS function that has a URL that references the document itself instead of an image.
Check the HTML
From my tests, this does not happen when the src attribute is empty but it happens when you set it to an anchor on the page.
So, in order to find the culprit, go to the Inspector (Firefox) or Elements (Chrome) panel, press Ctrl+F (Windows, Linux) or Cmd+F (macOS) and search for img[src^="#"]. That finds all <img> elements that have a src attribute with a value starting with a hash.
Check the CSS
Browsers (incorrectly) send a network request when the CSS url() function is set to an empty string, i.e. url(), url(''), or url("").
To check whether it is set within the style attribute of one of the HTML elements, search for url('') and url() within the Inspector as described above.
If it cannot be found there, you need to search within the style sheets.
Chrome
In Chrome this is possible by pressing Ctrl+Shift+F (Windows, Linux) or Cmd+Shift+F (macOS) while the focus is within the DevTools. Doing so opens a search tool that allows to search across all loaded sources. Type url('') in there and hit Enter. If nothing is found, try it again with url("") and url().
Firefox
In Firefox there's no such global search yet (as of Firefox 85), unfortunately. Though there are two ways other ways to search through the style sheets.
Via the Style Editor
The Style Editor allows you to inspect the style sheets, though you have to search in each one separately by selecting it at the left side and then pressing Ctrl+F (Windows, Linux) or Cmd+F (macOS), typing url(), url(''), or url("") and hitting Enter.
Via the Network Monitor
There's a feature that allows you to search through the network request reponses within the Network Monitor. Click the magnifying glass button, which opens the search tool. In the input field type url(), url(''), or url("") and hit Enter.
if I press F12, go to Elements and click ctrl+F to search for a xPath, if I find only one element, that element is not highlighted (but Chrome will point out 1 of 1). If i find more than one elements, Chrome highlights from the second one. Problem occures also when I use indexes in xPath: (//a)[1].
Seems like you are talking about this bug https://bugs.chromium.org/p/chromium/issues/detail?id=1106703 which was reported in the Chromium issue forums.
It was introduced in Chrome 84 with this change https://developers.google.com/web/updates/2020/05/devtools
I guess we can only wait or downgrade to Chrome 83 (which might not be possible in a corporate environment)
It seems Chrome returns every element with an attribute containing part of an url (meta with #content, script with #src,...). That's why you got a script element when //a is your input. However, (//a)[1] should work and should return the first anchor (tested fine with Edge Chromium and Chrome).
Try to use this workaround to select the element :
//a[self::a]
To get the first anchor on the page, use :
(//a[self::a])[1]
Images for reference :
The root cause is DevTools within Google Chrome 84.0 doesn't highlights the first matching element.
If, the locator finds a single match, the search result does show 1 of 1 but the WebElement isn't getting highlighted within the HTML DOM
As a demonstration, the Search Box within the Google Home Page can be identified uniquely using the css-selector:
[name='q']
or using the xpath:
//*[#name='q']
google-chrome-devtools within Google Chrome 84.0, does finds the element and shows 1 of 1 but the element is not getting highlighted.
Incase, there are multiple element matching to the Locator Strategy, barring the first matched element, the other elements does gets highlighted.
Bug in Chrome 84
This issue was raised within Platform>DevTools queue through Issue 1108311: The first matched element in the Elements panel is not getting highlighted as per the cssSelector and had been merged into Issue 1103316: Elements search does not resolveNode (highlight text, etc) on first search result where we are actively tracking the issue.
Solution
As per #bugdroid the main issue was caused because a check to ensure the search results were valid did not account for the case where the index was 0, so all highlight results of index 0 (index 1 to the user) were no longer highlighted.
The fix for this issue is Merge-Approved in:
Chrome version 84.0 later then Version 84.0.4147.89.
Chrome version 85.0.
Chrome Canary version 86.0.4201.0.
Alternate Solution
For alternate solutions using the current google-chrome Version 84.0.4147.89 you can find a detailed discussion in Why XPath does not highlighted the yellow mark in Chrome84?
As per usual when making automated tests I use "Inspect"(CTRL+SHIFT+I) in Chrome to find element by xpath, id, CSS selector etc.
For example:
//li/a[contains(text(), "Products")]
Above is an xpath from this page. In previous versions of Chrome in "DevTools"/"Elements" after pressing CTRL+F to open the "Find" option and pasting this xpath element is highlighted in DevTools window. In new version of chrome it is not highlighted, the usual "1/1" results is displayed in far right of the "Find" tab.
I've search the internet and Chrome Settings but to no avail.The yellow highlight is time saver and I know for certain that I am using the right element.
Edit: Fixed with Chrome version 84.0.4147.105
Thank you for updates, suggestions, workarounds etc.
Yes, In recent updates of Chrome 84, Find feature is buggy. 3 issues have been reported and those are in unconfirmed status as of now (while writing this answer). You can follow them on below links for more details -
An element in the elements tab is not highlighted if it is only one in the DOM
"Find" feature not working on "Elements" tab
Finding element/xpath wont direct to the object
Update
Elements search does not resolveNode (highlight text, etc) on first search result
Has been fixed and it is part of Version 84.0.4147.105 (Official Build) (64-bit). You just need to update and relaunch the chrome. The issues mentioned above are marked as duplicate to this issue.
The major issue is with DevTools within Google Chrome 84.0 which doesn't highlights the first matched element.
Incase, the locator finds a single match, the search result does show 1 of 1 but the WebElement is not highlighted within the DOM Tree
As an example, the Search Box within the Google Home Page can be identified uniquely using the css-selector:
[name='q']
or using the xpath:
//*[#name='q']
But google-chrome-devtools within Google Chrome 84.0, does finds the element and shows 1 of 1 but the element is not highlighted.
However, if there are multiple element matching to the Locator Strategy, leaving out the first matched element, the other elements are highlighted.
Bug in Chrome 84
This issue was raised in the Platform>DevTools queue through Issue 1108311: The first matched element in the Elements panel is not getting highlighted as per the cssSelector and had been merged into Issue 1103316: Elements search does not resolveNode (highlight text, etc) on first search result where we are actively tracking the issue.
Solution
As per #bugdroid the main issue was caused because a check to ensure the search results were valid did not account for the case where the index was 0, so all highlight results of index 0 (index 1 to the user) were no longer highlighted.
The fix for this issue is Merge-Approved in:
Chrome version 84.0 later then Version 84.0.4147.89.
Chrome version 85.0.
Chrome Canary version 86.0.4201.0.
Alternate Solution
For alternate solutions using the current google-chrome Version 84.0.4147.89 you can find a detailed discussion in Why XPath does not highlighted the yellow mark in Chrome84?
Also as a workaround you can try using chro path extension, where you can paste your written xpath in search box and see element getting highlighted in browser.
Additionally you will be able to get automatic locators formed by chropath itself
I have also faced a similar issue where first matched xpath is not visible in chrome ( mac os mojave).
As a workaround, I am using the chrome console for exactly locating the xpath element.
Steps :
Open developer tools
Click on Console tab
type command as : $x("xpath") and press enter.
Find the below image link for reference.
dev console
Another option is to go to console section and evaluate your xpath like this $x("yourXpath") and hit enter. In the case of google search button woulb be like this: $x("//*[#name='q']") then you hit enter and expand the structure that appears below and if you hover with the mouse, the element is going to be highlighted.
I had the same issue, but the thing is .....
you should after you position your cursor to a particular text or control or button(etc) that you wish to inspect, then right click and choose Inspect element, then in the area where you see the code...I mean in Element tab of the opened DevTools, keeping your cursor on the text of the code at any place, then click Ctrl+F and it will open a search field
and then you type an absolute or relative xpath of your element that you would like to find and when the path is correct, your text will be highlighted with yellow.
Surprisingly, if I just move my cursor out of element tab and still do Ctrl+F, the search field will open, but the element is not highlighted in yellow as before
I had started using firefox!
It is being fixed by chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=1103316.
Should be out soon.
This question is similar to How can I inspect disappearing element in a browser?, except it's the reverse.
I'm trying to debug which JS adds a bunch of rogue <iframe> aswift_1, aswift_2, etc. elements to the page, like so:
I'd like to use Chrome Devtools (or Firefox) to pause execution as soon as such an element is added and inspect the call stack, hopefully finding the culprit.
Other ideas are welcome as well.
You can use this simple chrome extension.
It will trigger the debugger AFTER element with id matching aswift_ is added(of course you need to open chrome dev tools first).
https://gist.github.com/maciejmackowiak/8043c8630004644144711f730ef45f1b
To activate this extension download -> unpack, open manifest.json and in line 8 change the example.com to the domain you want to inspect.
Then go to chrome://extensions/
Click on Developer mode and Load unpacked
When you will go to the page maching the domain this should show up after element with id starting with aswift_ is added:
Paused in debugger
Now you can use "step over next function call(F10)" (you may need to hit it few times before it will loop thru all mutations and "go" to another function)
Quickest way in chrome would be to take a look at either the network tab (for response) or do a global search using Ctrl+Shift+F on Windows and look for certain tags used in those elements which are being added to the DOM
In one of my PCs when I use inspect tool in chrome, I can't select some part of a property or a value, so I have to retype all the value again. As many times as I click on the selected text, the caret doesn't go to the place I need and the selected text doesn't deselect.
the following picture shows what I want and what happens.
There is no problem in another PC.
Both are windows 10 64bit and google chrome 62.
Try holding shift or control while clicking. Haven't tried it, but it may work. My guess is that it's simply a UX workflow that DevTools doesn't handle well.