Playwright: Click function not happening on visible element - xpath

I am trying to click on a link. I have verified the xpath for that element using SelectorsHub and Chropath as well, so there is no issue with the locator. I have tried 3-4 xpaths but I keep on getting the same error. Please see below the error which I am getting in console:-
locator.click: Target closed
=========================== logs ===========================
waiting for selector "//span[contains(text(),'Received Date')]/following-sibling::span/span/span[#aria-label='caret-up']"
selector resolved to visible <span role="img" aria-label="caret-up" class="anticon …>…
attempting click action
waiting for element to be visible, enabled and stable
element is visible, enabled and stable
scrolling into view if needed
done scrolling
checking that element receives pointer events at (485.95,278.14)
… intercepts pointer events
retrying click action, attempt #1
waiting for element to be visible, enabled and stable
element is visible, enabled and stable
scrolling into view if needed
done scrolling
checking that element receives pointer events at (485.95,278.14)
… intercepts pointer events
Please see below the HTML for this:-
<div class="ant-table-filter-column"><span class="ant-table-column-title"><div class="ant-table-column-sorters"><span class="ant-table-column-title">Received Date</span><span class="ant-table-column-sorter ant-table-column-sorter-full"><span class="ant-table-column-sorter-inner"><span role="img" aria-label="caret-up" class="anticon anticon-caret-up ant-table-column-sorter-up active"><svg viewBox="0 0 1024 1024" focusable="false" data-icon="caret-up" width="1em" height="1em" fill="currentColor" aria-hidden="true"><path d="M858.9 689L530.5 308.2c-9.4-10.9-27.5-10.9-37 0L165.1 689c-12.2 14.2-1.2 35 18.5 35h656.8c19.7 0 30.7-20.8 18.5-35z"></path></svg></span><span role="img" aria-label="caret-down" class="anticon anticon-caret-down ant-table-column-sorter-down"><svg viewBox="0 0 1024 1024" focusable="false" data-icon="caret-down" width="1em" height="1em" fill="currentColor" aria-hidden="true"><path d="M840.4 300H183.6c-19.7 0-30.7 20.8-18.5 35l328.4 380.8c9.4 10.9 27.5 10.9 37 0L858.9 335c12.2-14.2 1.2-35-18.5-35z"></path></svg></span></span></span></div></span><span role="button" tabindex="-1" class="ant-dropdown-trigger ant-table-filter-trigger"><span role="img" aria-label="search" class="anticon anticon-search"><svg viewBox="64 64 896 896" focusable="false" data-icon="search" width="1em" height="1em" fill="currentColor" aria-hidden="true"><path d="M909.6 854.5L649.9 594.8C690.2 542.7 712 479 712 412c0-80.2-31.3-155.4-87.9-212.1-56.6-56.7-132-87.9-212.1-87.9s-155.5 31.3-212.1 87.9C143.2 256.5 112 331.8 112 412c0 80.1 31.3 155.5 87.9 212.1C256.5 680.8 331.8 712 412 712c67 0 130.6-21.8 182.7-62l259.7 259.6a8.2 8.2 0 0011.6 0l43.6-43.5a8.2 8.2 0 000-11.6zM570.4 570.4C528 612.7 471.8 636 412 636s-116-23.3-158.4-65.6C211.3 528 188 471.8 188 412s23.3-116.1 65.6-158.4C296 211.3 352.2 188 412 188s116.1 23.2 158.4 65.6S636 352.2 636 412s-23.3 116.1-65.6 158.4z"></path></svg></span></span></div>
Below are the xpaths which I have tried:-
//*[text()='Received Date']/following-sibling::span/span/span[#aria-label='caret-up']
//thead/tr[1]/th[4]/div[1]/span[1]/div[1]/span[2]/span[1]/span[1]
//span[contains(text(),'Received Date')]/following-sibling::span/span/span[#aria-label='caret-up']
Code for clicking - await this.page.locator("//span[contains(text(),'Received Date')]/following-sibling::span/span/span[#aria-label='caret-up']").click();

Please, try to avoid very long or complex Xpaths. They make your code unreadable, they can make errors and they are not the right way to find elements and click on them.
Tell me if this works for you:
button = self.page.locator('//span[contains(text() \
,'Received Date')]').first
button.click()

Related

Submit text field using watir

I am trying to programmatically submit text into a text field using watir. I'm using Stack Overflow as a test site for the script.
I was able to reference the search field (name='q') but the submit button doesn't have an id or name attribute. So how do you reference the submit button programmatically and click it?
This is the code I have so far:
require 'watir'
require 'pry'
browser = Watir::Browser.new :chrome, headless: true
browser.goto 'https://www.stackoverflow.com'
browser.text_field(:name, "q").set('user:963076') #the search bar name='q'
browser.button(#how do I reference the submit button?, '').click
browser.screenshot.save 'screenafter.png' #the screenshot is so that I know what happened after clicking
browser.close
browser.quit
A direct answer to the question is good, but an explanation about how to find solutions to problems like this on your own is better and very much appreciated.
You have to click this button
<button type="submit" aria-label="Search..." class="s-btn s-btn__primary btn-topbar-primary js-search-submit"><svg aria-hidden="true" class="svg-icon mx0 iconSearch" width="18" height="18" viewBox="0 0 18 18"><path d="M12.86 11.32L18 16.5 16.5 18l-5.18-5.14v-.35a7 7 0 1 1 1.19-1.19h.35zM7 12A5 5 0 1 0 7 2a5 5 0 0 0 0 10z"></path></svg></button>
The button has the type attribute with the value of submit so we can use that to locate that button, here is the code
browser.goto 'https://www.stackoverflow.com'
browser.text_field(name: "q").set('user:963076')
browser.button(type: 'submit').click

NSDrawer causes crash when added to App Window

I'm trying to programmatically add an NSDrawer to my app's main window (which also has an NSOutlineViewwhich was setup in IB):
Ivar:
var dd: NSDrawer? = nil
Then, when a disclosure triangle button is clicked:
if dd == nil {
var drawer_rect = NSInsetRect(self.window.frame, 30, 30).size
drawer_rect.height = 150
dd = NSDrawer.init(contentSize: drawer_rect, preferredEdge: NSRectEdge.minY)
dd!.contentView = self.status_scroll
dd!.parentWindow = self.window
}
So when the user tries to 'disclose' the drawer, the above code creates an NSDrawer and then displays it. It all works fine but Xcode dumps the following out as the parentWindow is set:
[General] ERROR: Setting <NSOutlineView: 0x100f0b9b0> as the first responder for window <NSDrawerWindow: 0x100fc8900>, but it is in a different window (<NSWindow: 0x6080001e0600>)! This would eventually crash when the view is freed. The first responder will be set to nil.
(
0 AppKit 0x00007fff9fc289cf -[NSWindow _validateFirstResponder:] + 557
1 AppKit 0x00007fff9f3a374c -[NSWindow _setFirstResponder:] + 31
2 AppKit 0x00007fff9f90c35b -[NSDrawerWindow _setParentWindow:] + 64
3 AppKit 0x00007fff9f90b666 -[NSDrawer(DrawerInternals) _doSetParentWindow:] + 382
4 AppKit 0x00007fff9f907786 -[NSDrawer setParentWindow:] + 78
Comment out the setting of the parentWindow and nothing gets dumped to the console.
NSDrawer is deprecated as per Apple documentation. You should consider a different design. If you still use NSDrawer, you may face such issues.

Zebra MZ320 - feeds few lines after black mark is found

I am working with Zebra MZ320 printer to integrate Black mark. I am facing issue when black mark is set to True. The printer feeds 2-3 line after black mark is encountered on paper
The command used to calibrate black mark successfully :
! DF CONFIG.SYS
! UTILITIES
BAR-SENSE
LABEL
PRINT
Sample print text :
! 0 200 200 700 1
COUNTRY UK
COUNTRY UK
TEXT 4 0 0 0 -----------------------------------
TEXT 4 0 0 20 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 50 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 80 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 120 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 150 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 180 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 220 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 260 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 310 xxxxxxxxxxxxxxxxxxxxxxxxxxx
TEXT 4 0 0 350 xxxxxxxxxxxxxxxxxxxxxxxxxxx
! DF CONFIG.SYS
! UTILITIES
BAR-SENSE
SETFF 0 0
LABEL
PRINT
I have seen many links that prevent extra feeding but they work with FORM / Continuous mode
Already visited and tried these links :
Zebra iMZ320 image printing feeds too much paper
Stop my mobile printer from feeding extra paper using continuous roll?
Stop a Zebra Printer from automatically feeding lots of extra pape
It seems I am missing some configuration while sending commands to printer. Any suggestion is appreciated.
Sometimes these printers need calibration, did you calibrate it? See the calibration procedure in the user manual.
You can recalibrate the printer with Zebra Tools but also with ZPL commands. Sometimes only recalibration with ZPL commands helps.

MKMapView setRegion: animated: crashes the app (edited)

I have a MKMapView that expands (vertically) on tap (using UITapGestureRecognizer) and fires off an api call on pan (using UIPanGestureRecoginizer).
Everything was working fine, until some time back, where on Panning, the app would crash, with hardly any useful info (or info that I could comprehend)
Exception breakpoints are on, and zombie objects have been enabled. On crashing, it never hits the exception breakpoint!
Here's the log:
(Panning began, panning, panning ended are printed out based on the Pan gestureRecognizer states).
Right after panning ends, the app crashes.
(The map is yet to load all its tiles, and regionDidChangeAnimated is not called yet):
2013-01-17 14:46:04.396 MyApp[13126:c07] Panning Began
2013-01-17 14:46:04.412 MyApp[13126:c07] Panning
2013-01-17 14:46:04.412 MyApp[13126:c07] Panning
2013-01-17 14:46:04.557 MyApp[13126:c07] Panning
2013-01-17 14:46:04.606 MyApp[13126:c07] Panning
2013-01-17 14:46:04.691 MyApp[13126:c07] Panning Ended
2013-01-17 14:46:04.692 MyApp[13126:c07] *** -[MKMapViewPositioningChange hasChanges]: message sent to deallocated instance 0x139f7520
Here's the backtrace i see after the crash:
(lldb) bt
* thread #1: tid = 0x1c03, 0x02a4fa97 CoreFoundation`___forwarding___ + 295, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x02a4fa97 CoreFoundation`___forwarding___ + 295
frame #1: 0x02a4f94e CoreFoundation`_CF_forwarding_prep_0 + 14
frame #2: 0x01244d27 MapKit`-[MKMapView(UserPositioningInternal) _runPositioningChange] + 2037
frame #3: 0x01242dd7 MapKit`-[MKMapView(UserPositioningInternal) _runPositioningChangeIfNeeded:] + 86
frame #4: 0x01240220 MapKit`-[MKMapViewInternal runPositioningChangeIfNeeded] + 50
frame #5: 0x01e2eb90 Foundation`__NSFireTimer + 97
frame #6: 0x02a1f376 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
frame #7: 0x02a1ee06 CoreFoundation`__CFRunLoopDoTimer + 534
frame #8: 0x02a06a82 CoreFoundation`__CFRunLoopRun + 1810
frame #9: 0x02a05f44 CoreFoundation`CFRunLoopRunSpecific + 276
frame #10: 0x02a05e1b CoreFoundation`CFRunLoopRunInMode + 123
frame #11: 0x03c897e3 GraphicsServices`GSEventRunModal + 88
frame #12: 0x03c89668 GraphicsServices`GSEventRun + 104
frame #13: 0x0132d65c UIKit`UIApplicationMain + 1211
frame #14: 0x0001223d MyApp`main + 141 at main.m:16
frame #15: 0x00002fc5 MyApp`start + 53
The crashes go away the moment i take the connection for the PanGestureRecognizer action method.
Is there a way to get rid of this crash while using the gesture recognizers? or is there a way to know that the map was tapped and panned, without using GestureRecognizers?
Any help/questions/answers/comments appreciated!
Update (Jan 19): This doesn't seem to be an issue with the pan gesture recognizer at all. Now I am getting it to crash on after i try to add new annotations to the mapview, call [MapView setRegion: animated:], and crashes just before regionDidChangeAnimated is hit, with the same [MKMapViewPositioningChange hasChanges] log at the point where it crashes.
Update (Jan 23): I think I am quite sure whats happening. there is one chunk of code thats trying to set the region to include all the annotations in the visible rect of the MKMapView, and a few other locations, where I am calling [myMapView removeAnnotations:[myMapView annotations]]. And, my guess is that these two actions end up in a nasty mid-air collision, leaving no trail as to what lead to a crash. Will update the question with an answer if my hunch-fix passes QA
As I had guessed earlier (second update to the question), this was an issue with trying the add set the map region to show all annotations, and removing all annotations simultaneously. if you are calling setRegion: animated: , make sure to check if the mapView has at least one annotation.
Also, it'll be helpful to use the following piece of code judiciously, especially if you are doing any type of animations on the map based on the annotations.
[MKMapView removeAnnotations:[MKMapView annotations]];

Core Data throws NSInternalInconsistencyException "The context is still dirty after 100 attempts."

I struggle finding cause of the following exception. It occurs from time to time with no clear pattern I can repeat to reproduce problem.
Terminating app due to uncaught exception 'NSInternalInconsistencyException',
reason: 'Failed to process pending changes before save.
The context is still dirty after 100 attempts.
Typically this recursive dirtying is caused by a bad validation method,
-willSave, or notification handler.'
The application stores and process tracking data and deals with only one entity:
#interface CSTrackingEntry : NSManagedObject
#property (nonatomic, retain) NSString * data;
#property (nonatomic, retain) NSDate * dateRecorded;
#end
CSTracking entries are read, created and deleted in batches. Few up to dozen in a batch, once every couple of minutes. There is no notification handlers registered.
UPDATE: Stack captured
2012-02-03 10:26:11.121 BatteryNurse[17162:1803] An uncaught exception was raised
2012-02-03 10:26:11.121 BatteryNurse[17162:1803] Failed to process pending changes
before save. The context is still dirty after 100 attempts. Typically this recursive
dirtying is caused by a bad validation method, -willSave, or notification handler.
2012-02-03 10:26:11.264 BatteryNurse[17162:1803] *** Terminating app due to uncaught
exception 'NSInternalInconsistencyException', reason: 'Failed to process pending changes
before save. The context is still dirty after 100 attempts. Typically this recursive
dirtying is caused by a bad validation method, -willSave, or notification handler.'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff8183f784 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff89306f03 objc_exception_throw + 45
2 CoreData 0x00007fff8543a654 -[NSManagedObjectContext(_NSInternalChangeProcessing) _prepareForPushChanges:] + 244
3 CoreData 0x00007fff8543a0af -[NSManagedObjectContext save:] + 207
4 BatteryNurse 0x0000000100075ee6 __40-[CSTrackingEntry(Methods) deleteObject]_block_invoke_0 + 102
5 BatteryNurse 0x000000010007514f __42-[CSCoreDataKernel(CoreData) executeSync:]_block_invoke_0 + 79
6 libSystem.B.dylib 0x00007fff869bcfbb dispatch_barrier_sync_f + 79
7 BatteryNurse 0x00000001000750ee -[CSCoreDataKernel(CoreData) executeSync:] + 110
8 BatteryNurse 0x0000000100075e6f -[CSTrackingEntry(Methods) deleteObject] + 175
9 CoreFoundation 0x00007fff817ff123 -[NSArray makeObjectsPerformSelector:] + 499
10 BatteryNurse 0x000000010003a13f -[CSTracker(PrivateMethods) processAndSendBundlesToServer] + 383
11 BatteryNurse 0x00000001000393a4 __23-[CSTracker flushAsync]_block_invoke_0 + 420
12 libSystem.B.dylib 0x00007fff869c3d64 _dispatch_call_block_and_release + 15
13 libSystem.B.dylib 0x00007fff869a28d2 _dispatch_queue_drain + 251
14 libSystem.B.dylib 0x00007fff869a2734 _dispatch_queue_invoke + 57
15 libSystem.B.dylib 0x00007fff869a22de _dispatch_worker_thread2 + 252
16 libSystem.B.dylib 0x00007fff869a1c08 _pthread_wqthread + 353
17 libSystem.B.dylib 0x00007fff869a1aa5 start_wqthread + 13
You are modifying the object while it's being saved. If you're observing NSManagedObjectContextObjectsDidChange (which will be posted as part of the save, but before the actual saving happens), and you change objects are a result of that notification, you'll create a loop:
When you call -save: CoreData first calls -processPendingChanges: (if there are changes). As part of that CoreData sends out an NSManagedObjectContextObjectsDidChange notification. If additional objects changed while the notification was being processed, it calls -processPendingChanges: again, sends out the notification again, etc. Once there are no pending changes, CoreData persists the objects to the store. If pending changes keep appearing CoreData will eventually give up and print
The context is still dirty after 100 attempts.
That's the gist of it.

Resources