Weird behavior while Suppress "Bookmarks" button in SAPUI5, Fiori - html

Some times ago i've successfully suppressed the "Save as Tile" button that exists in the Standard Fiori App, MM_PO_APV:
// Standard application buttons (Remove Forward)
this.setHeaderFooterOptions({
oPositiveAction: {
sI18nBtnTxt: that.resourceBundle.getText("XBUT_APPROVE"),
onBtnPressed: jQuery.proxy(that.handleApprove, that)
},
oNegativeAction: {
sI18nBtnTxt: that.resourceBundle.getText("XBUT_REJECT"),
onBtnPressed: jQuery.proxy(that.handleReject, that)
},
onBack: jQuery.proxy(function() {
//Check if a navigation to master is the previous entry in the history
var sDir = sap.ui.core.routing.History.getInstance().getDirection(this.oRouter.getURL("master"));
if (sDir === "Backwards") {
window.history.go(-1);
} else {
//we came from somewhere else - create the master view
this.oRouter.navTo("master");
}
}, this),
// Remove the 'Save as Tile' button
bSuppressBookmarkButton : true
});
But they had updated the SAPUI5 version, I think the lastest, and it comes with a problem. The button is appearing, but with a weird behavior, as you can see:
All my code remains the same, and as I've seen on documentation API, it remains the same too.
Could you help me on how to resolve this?
Regards,
Andre

The most likely cause for this would be the UI5 version(the latest update that you mentioned).
Try one of these two things,
Clear cache and re-run the application
Revert to a previous UI5 version or update to a new version
Contact the respective support team(Scaffolding team I assume) if these don't help.

This should work:
//Prevent overflow button (...) in footer
this.oApplicationImplementation.oDHFHelper.oCommonHeaderFooterHelper.bAutomaticOverflow = false;
Put this code in the onInit method of the controller extension.

Related

Navigating to a page in a custom event doesn't work properly

When I navigate to a page using this event:
this.events.subscribe('liveTrackingEvent', (time, unit) => {
console.log("event triggered");
this.searchForm.controls['unitID'].setValue(this.unitSelected.unit.name);
this.GetLiveData();
});
everything gets called, also the function GetLiveData(). (I didn't post this function's code because it's irelevant)
However when I look at the page, not 1 element is updating. So this line:
this.searchForm.controls['unitID'].setValue(this.unitSelected.unit.name);
doesn't update the searchform control, however when I call this line of code from the page itself without the event getting triggered on another page, it works smoothly and updates the searchform control.
(It's like I'm on a separate thread for some reason), I'm putting this between brackets because it's just a thought.
So my question is: How do I force this page to update itself also when the event is triggered?
Thanks in advance and if you guys need more code just ask, but this is the most relevant code because everything is working just not when it gets called inside the event.
By using page life cycle events instead of custom events from the ionic framework I managed to make this work and even have a cleaner code.
example:
1st page:
GoToLiveTracking(unitID){
this.navCtrl.push(MapPage, {redirected: true, unitID: unitID});
}
2nd page:
ionViewDidEnter(){
if(this.navParams.get('redirected')){
let unit_id = this.navParams.get('unitID');
this.unitSelected = this.completeService.GetUnitByID(unit_id);
this.searchForm.controls['unitID'].setValue(this.unitSelected.unit.name);
this.GetLiveData();
}
}
I could think of only 1 reason for this behavior. You are updating your form outside of Angular Zone. That’s why the changes are not getting detected.
To fix the issue, wrapped the call of last 2 lines of event into “this.ngZone.run(() => { ... })”.
e.g
this.events.subscribe('liveTrackingEvent', (time, unit) => {
console.log("event triggered");
this.ngZone.run(()=>{
this.searchForm.controls['unitID'].setValue(this.unitSelected.unit.name);
this.GetLiveData();
});
});

mobile: how to prevent pull-to-refresh

How to prevent pull-to-refresh in web applications for Chrome android?
I tried the answers from
Disabling android's chrome pull-down-to-refresh feature
body {
overflow-y: hidden;
}
or
body {
touch-action: none;
}
It did not work. any one has a solution that works? It is very bad for browsers to make pull-to-refresh default behavior, it is very undesirable for web applications.
Here's a CSS method of capturing the required touch gestures to prevent the pull to refresh:
$("html").css({
"touch-action": "pan-down"
});
This method seems to have worked well for other users. Hope it works for your needs.
Reference, plus there's more strategies discussed here:
Disabling android's chrome pull-down-to-refresh feature
The code below is a javascript-only solution distilled from a couple of sources, which are towards the bottom.
If you are willing to change the structure of your pages, a CSS/HTML only option may work for you.
Additionally, the draft CSS property scroll-boundary-behavior is in the process of being standardized and added to Chrome provide this capability among a few others. As the implementation is very, very new, I provide links at the bottom of my answer.
Example
although jsfiddle's iframe structure prevents pull-to-refresh from working at all, I also tested the same script within a flat HTML document on Chrome Android 60.0.3112.116.
Full jsfiddle
event.preventDefault() can keep browser default behaviors such as pull-to-refresh from taking place. We want the usual browser behavior most of the time, just not when it would lead to a pull-to-refresh. Since a pull-to-refresh happens when touches are moving down the screen and we're scrolled to the top of the document, we'll only call preventDefault under those conditions.
//We're going to make a closure that will handle events
//so as to prevent the pull-to-refresh behavior.
var pullToRefreshPreventer = (function() {
//To determine the direction in which a touch is moving,
//we hold on to a map from touch identifier to touches
//from the previous event.
var previousTouches = {};
return function(event) {
//First we get all touches in this event and set up
//the value which will replace `previousTouches`
//before this event handler exits.
var touches = Array.prototype.slice.call(event.touches);
nextTouches = {}
touches.forEach(function(touch){
nextTouches[touch.identifier] = touch;
});
//Pull-to-refresh behavior only happens if we are
//scrolled to the top of the document, so we can
//exit early if we are somewhere in the middle.
if(document.scrollingElement.scrollTop > 0) {
previousTouches = nextTouches;
return;
}
//Now we know that we are scrolled to the top of
//the document;
//look through the current set of touches and see
//if any of them have moved down the page.
for(var ix = 0; ix < touches.length; ix++) {
var touch = touches[ix],
id = touch.identifier;
//If this touch was captured in a previous event
//and it has moved downwards, we call preventDefault
//to prevent the pull-to-refresh behavior.
if(id in previousTouches && previousTouches[id].screenY < touch.screenY) {
event.preventDefault();
console.log("event.preventDefault() called")
break;
}
}
//lastly, we update previousTouches
previousTouches = nextTouches;
};
}());
//Since touch events which may call `preventDefault` can be
//much more expensive to handle, Chrome disallows such calls
//by default. We must add the options argument `{passive: false}`
//here to make it work.
document.body.addEventListener('touchmove', pullToRefreshPreventer, {passive: false});
document.body.addEventListener('touchend', pullToRefreshPreventer, {passive: false});
References:
StackOverflow answer linking to chromestatus.com page
"Treat Document Level Touch Event Listeners as Passive", chromestatus
"Making touch scrolling fast by default"
"Touch events"
scroll-boundary-behavior links:
chromestatus
chromium bug
github issue proposing the standard
draft css module, last publish date 2017-09-07

Strange IE11 form fields bug after selecting from dropdown

I'm experiencing a major bug in IE 11 (latest version 11.0.9600.16521 on Windows 7). When on any form if I open a select dropdown all the other form fields on the page freeze. I can 'unfreeze' them by adjusting the Window size (causing a redraw). This seems to happen on any form what-so-ever.
To reproduce:
Open IE 11.0.9600.16521
Go to http://www.wikipedia.org/
Select any language from the language dropdown
Result:
language dropdown does not appear to get updated on the screen
the search box appears to be frozen - i.e. focus on select box and start typing but no text appears. However if you adjust the window size the form fields are updated and go back to working as normal (until you interact with another select element)
I can't find much in Google for this issue so maybe it's just something specific to my settings. Only thing that sounds somewhat similar to what I'm experiencing is this: http://connect.microsoft.com/IE/feedback/details/806679/ie-11-desktop-selecting-an-item-from-a-drop-down-list-on-a-webpage-causes-the-tab-to-crash. Anyone else able to reproduce this?
I had a similar issue with IE11 that turned out to be any modification to the .text property of an SELECT-option element. I eventually found the "hint" on stackoverflow here
How to fix IE select issue when dynamically changing options.
In my case I use straight JavaScript, and with so many inter-dependent SELECT boxes had to come up with a generic solution, so my solution was to intercept (defineGetter) assignment to any .text property of an HTMLOptionElement, and set a 1 ms timer to perform an add element and remove element as in the referenced post that is titled "I have the fix. We have to add and remove options list to trigger the rendering in IE8." Notice the reference to IE8, AFAIK IE has had several issues with SELECT boxes since at least IE7, possibly earlier.
So the code I added to one of my global scripts is as follows:
try { var IE11; // IE10 and IE11 removed ActiveXObject from the window object but it can still be instantiated
IE11 = new ActiveXObject('MSXML2.DOMDocument.6.0');
IE11 = null;
if (typeof(HTMLOptionElement) != "undefined") {
try { HTMLOptionElement.prototype.__defineSetter__(
'text',
function(original) {
return function(newValue) { var sel;
original.call(this, newValue);
if (!(sel=this.parentElement).fixIE) sel.fixIE = window.setTimeout(_fixIE_(sel), 1);
}
}(HTMLOptionElement.prototype.__lookupSetter__('text')));
} catch(e) {};
}
} catch(e) {}
}
// IE11 broke SELECT boxes again, modifying any options .text attribute "freezes" the SELECT so it appears disabled
function _fixIE_(selBox) {
return _fixIE_;
function _fixIE_(){ var lc = selBox.options.length;
selBox.options.add(new Option('',''));
selBox.options.remove(lc);
selBox.fixIE = undefined;
}
}
Phil
Go to programs
Then widdcom folder
Right click bttray
Go compatibility
Tick run as admin
Restart
I had the same problem in IE 11 on Dell Windows 7.
It was solved by turning off hardware rendering in IE, as you suggested in your link.

SmartGWT TabSet.destroy() and recreation

I was having ID collision of tab IDs when trying to recreate the same TabSet.
My case is the following : I have 3 Tabs in general, then some action creates a 4th one, some action happens in this 4th tab which is then closed, and I need to relaunch my app and redraw again the 3 general Tabs fetching new info from the database. Everything was working well, except this warning of collision which was not a blocking one anyway.
In order to clean it, I followed Isomorphic's advice from this thread
and tried destroying the TabSet in order to recreate it.
I do:
if (myTabSet != null) {
myTabSet.destroy();
}
myTabSet = new TabSet();
// setting TabSet properties
// creating Tabs and adding them to the TabSet
I noticed, however, in debug, that the TabSet is not being desroyed completely, just some of its properties, and that a new ID is being given to it. As a result, there are no more warnings, the tabs are created, but they're not populated.
My question is : why the TabSet is not becoming null upon destruction, and how can I recreate it with no collision of IDs?
Thanks in advance
I used to have the same problem and fixed it with:
myTabSet.addCloseClickHandler(new CloseClickHandler() {
#Override
public void onCloseClick(TabCloseClickEvent event) {
event.getTab().getPane().destroy();
}
});
Apparently the tabset is not completely destroyed unless you destroy its pane.
Maybe it will work for you !

Debugging "Element is not clickable at point" error

I see this only in Chrome.
The full error message reads:
"org.openqa.selenium.WebDriverException: Element is not clickable at point (411, 675). Other element would receive the click: ..."
The element that 'would receive the click' is to the side of the element in question, not on top of it and not overlapping it, not moving around the page.
I have tried adding an offset, but that does not work either. The item is on the displayed window without any need for scrolling.
This is caused by following 3 types:
1.The element is not visible to click.
Use Actions or JavascriptExecutor for making it to click.
By Actions:
WebElement element = driver.findElement(By("element_path"));
Actions actions = new Actions(driver);
actions.moveToElement(element).click().perform();
By JavascriptExecutor:
JavascriptExecutor jse = (JavascriptExecutor)driver;
jse.executeScript("scroll(250, 0)"); // if the element is on top.
jse.executeScript("scroll(0, 250)"); // if the element is on bottom.
or
JavascriptExecutor jse = (JavascriptExecutor)driver;
jse.executeScript("arguments[0].scrollIntoView()", Webelement);
Then click on the element.
2.The page is getting refreshed before it is clicking the element.
For this, make the page to wait for few seconds.
3. The element is clickable but there is a spinner/overlay on top of it
The below code will wait until the overlay disppears
By loadingImage = By.id("loading image ID");
WebDriverWait wait = new WebDriverWait(driver, timeOutInSeconds);
wait.until(ExpectedConditions.invisibilityOfElementLocated(loadingImage));
Then click on the element.
You can also use JavaScript click and scrolling would be not required then.
IJavaScriptExecutor ex = (IJavaScriptExecutor)Driver;
ex.ExecuteScript("arguments[0].click();", elementToClick);
There seems to be a bug in chromedriver for that (the problem is that it's marked as won't fix)
--> GitHub Link
(place a bounty on FreedomSponsors perhaps?)
There's a workaround suggested at comment #27.
Maybe it'll work for you-
I had the same issue, tried all offered solutions but they did not work for me.
eventually I used this:
JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("var evt = document.createEvent('MouseEvents');" + "evt.initMouseEvent('click',true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0,null);" + "arguments[0].dispatchEvent(evt);", findElement(element));
Hope this helps
Wow, a lot of answers here, and many good ones.
I hope I'll add something to this from my experience.
Well guys, in my case there was a cookie overlay hiding the element occasionally.
Scrolling to the element also works; but in my humble opinion (for my case, not a panacea for everyone) the simplest solution is just to go full screen (I was running my scripts on a 3/4 of the screen window)! So here we go:
driver.manage().window().maximize();
Hope that helps!
You need to use focus or scroll on that element. You also might have to use explict wait.
WebElement firstbutton= driver.findElement(By.xpath("Your Element"));
Actions actions = new Actions(driver);
actions.moveToElement(element);
actions.perform();
OR
The element is not clickable because of a Spinner/Overlay on top of it:
By loadingImage = By.id("loading image ID");
WebDriverWait wait = new WebDriverWait(driver, timeOutInSeconds);
wait.until(ExpectedConditions.invisibilityOfElementLocated(loadingImage));
OR
Point p= element.getLocation();
Actions actions = new Actions(driver);
actions.moveToElement(element).movebyoffset(p.x,p.y).click().perform();
OR
If still not work use JavascriptExecutor
JavascriptExecutor executor = (JavascriptExecutor)driver;
executor.executeScript("arguments[0].click();", firstbutton);
I have seen this in the situation when the selenium driven Chrome window was opened too small. The element to be clicked on was out of the viewport and therefore it was failing.
That sounds logical... real user would have to either resize the window or scroll so that it is possible to see the element and in fact click on it.
After instructing the selenium driver to set the window size appropriately this issues went away for me. The webdriver API is decribed here.
I was getting this error when running tests headless with xvfb-run. They were working flawlessly locally. Using chrome, versions of webdriver / chromedriver / chrome / java etc all identical.
The ‘won’t fix’ bug in chromedriver - GitHub Link pointed out by Tony Lâmpada suggested this may be related to what is / isn't visible on the screen.
Help message for xvfb-run shows the following:
-s ARGS --server-args=ARGS arguments (other than server number and
"-nolisten tcp") to pass to the Xvfb server
(default: "-screen 0 640x480x8")
Changing the resolution for xvfb made the error go away:
xvfb-run -s "-screen 0 1280x1024x16" ...
ruby/watir-webdriver/chrome
I use the following trick and seems like it works:
#scroll to myelement
#browser.execute_script "window.scrollTo(#{myelement.element.wd.location[0]},#{myelement.element.wd.location[1]})"
# click myelement
myelement.when_present.fire_event("click")
I, too, wrestled with this problem. Code works fine in FF, fails on Chrome. What I was trying to do was to click a tickbox - if it wasn't in view, I'd scroll to view and then click. Even scrolling into view works in Chrome, only the bottom few pixels of the tickbox wasn't visible so webdriver refused to click on it.
My workaround is this:
WebElement element = _sectorPopup.findElement(...);
((Locatable) element).getCoordinates().inViewPort();
try {
element.click();
} catch (Exception e) {
new Actions(getWebDriver()).sendKeys(Keys.PAGE_DOWN).perform();
element.click();
}
Chrome also has issues with sendKeys, using Actions is sometimes necessary. Obviously, you need to know which direction and how much you need to go so your mileage may vary. But I prefer this to the javascript hack, so I'm posting it here in case someone else will find it useful.
First, try to get the latest Chrome driver and check if it solves the issue.
In my case, it didn't fix the issue. But, the following solution worked for me so far. The following is C# code but you can follow same logic in your specific language. What we do here is,
Step 1: Focus on the element using the Selenium Actions object,
Step 2: Then do a click on the element
Step 3: If there's an exception, then we trigger a javascript "Click" event on the element by executing the javascript script through the Selenium browser driver's "ExecuteScript" method.
You can also skip step 1 and 2 and try only step 3 too. Step 3 would work on it's own but I noticed some strange behavior in one scenario in which step 3, even though it successfully clicked the element, caused unexpected behavior in other parts of my code after clicking the element.
try
{
//Setup the driver and navigate to the web page...
var driver = new ChromeDriver("folder path to the Chrome driver");
driver.Navigate().GoToUrl("UrlToThePage");
//Find the element...
var element = driver.FindElement(By.Id("elementHtmlId"));
//Step 1
new Actions(driver).MoveToElement(element).Perform();
//Step 2
element.Click();
}
catch (Exception)
{
//Step 3
driver.ExecuteScript("document.getElementById('elementHtmlId').click();");
}
I was getting the same issue while running selenium script in python. Here is what I used to click on the element:
from selenium.webdriver.common.action_chains import ActionChains
ActionChains(driver).click(element).perform()
When using Protractor this helped me:
var elm = element(by.css('.your-css-class'));
browser.executeScript("arguments[0].scrollIntoView();", elm.getWebElement());
elm.click();
I made this method based on a comment from Tony Lâmpada's answer. It works very well.
def scroll_to(element)
page.execute_script("window.scrollTo(#{element.native.location.x}, #{element.native.location.y})")
end
Today I got the same kind of issue. You don't believe me if i say how i solved the issue.
By maximizing the browser size
Yes, it is a pointer issue that means the size of the browser. For that, you just need to maximize the window size manually or through the code.
I was facing a similar problem whre i have to check two check boxes one after the other.But i was getting the same above error.hence i added wait in between my steps for checking the checkboxes....its working fine and great.here are the steps:-
When I visit /administrator/user_profiles
And I press xpath link "//*[#id='1']"
Then I should see "Please wait for a moment..."
When I wait for 5 seconds
And I press xpath link "//*[#id='2']"
Then I should see "Please wait for a moment..."
When I visit /administrator/user_profiles_updates
The reason for this error is that the element that you are trying to click is not in the viewport (region seen by the user) of the browser. So the way to overcome this is by scrolling to the desired element first and then performing the click.
Javascript:
async scrollTo (webElement) {
await this.driver.executeScript('arguments[0].scrollIntoView(true)', webElement)
await this.driver.executeScript('window.scrollBy(0,-150)')
}
Java:
public void scrollTo (WebElement e) {
JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeAsyncScript('arguments[0].scrollIntoView(true)', e)
js.executeAsyncScript('window.scrollBy(0,-150)')
}
Apparently this is the result of a "Won't Fix" bug in the Chrome driver binary.
One solution that worked for me (Our Mileage May Vary) can be found in this Google Group discussion, Comment #3:
https://groups.google.com/forum/?fromgroups=#!topic/selenium-developer-activity/DsZ5wFN52tc
The relevant portion is right here:
I've since worked around the issue by navigating directly to the href of
the parent anchor of the span.
driver.Navigate().GoToUrl(driver.FindElement(By.Id(embeddedSpanIdToClick)).FindElement(By.XPath("..")).GetAttribute("href"));
In my case, I'm using Python, so once I got the desired element, I simply used
driver.get(ViewElm.get_attribute('href'))
I would expect this to only work, however, if the element you are trying to click on is a link...
Re Tony Lâmpada's answer, comment #27 did indeed solve the problem for me, except that it provided Java code and I needed Python. Here's a Python function that scrolls to the element's position and then clicks it.
def scroll_to_and_click(xpath):
element = TestUtil.driver.find_element_by_xpath(xpath)
TestUtil.driver.execute_script('window.scrollTo(0, ' + str(element.location['y']) + ');')
element.click()
This solved the problem for me in Chrome 34.0. It caused no harm in Firefox 28.0 and IE 11; those browsers aren't subject to the problem, but scrolling to the element's position before clicking it still isn't a bad thing.
This might happen if the element changes position while the driver is attempting to click it (I've seen this with IE too). The driver retains the initial position but by the time it actually gets to clicking on it, that position is no longer pointing to that element. The FireFox driver doesn't have this problem BTW, apparently it "clicks" elements programmatically.
Anyway, this can happen when you use animations or simply change the height of elements dynamically (e.g. $("#foo").height(500)). You need to make sure that you only click elements after their height has "settled". I ended up with code that looks like this (C# bindings):
if (!(driver is FirefoxDriver))
{
new WebDriverWait(driver, TimeSpan.FromSeconds(10)).Until(
d => d.FindElement(By.Id(someDynamicDiv)).Size.Height > initialSize);
}
In case of an animation or any other factor you can't easily query for, you can utilize a "generic" method that waits for the element to be stationary:
var prevLocation = new Point(Int32.MinValue, Int32.MinValue);
int stationaryCount = 0;
int desiredStationarySamples = 6; //3 seconds in total since the default interval is 500ms
return new WebDriverWait(driver, timeout).Until(d =>
{
var e = driver.FindElement(By.Id(someId));
if (e.Location == prevLocation)
{
stationaryCount++;
return stationaryCount == desiredStationarySamples;
}
prevLocation = e.Location;
stationaryCount = 0;
return false;
});
I met this because a loading dialog cover on this element. I simplely solve it by add a waiting before working with the this element.
try {
Thread.sleep((int) (3000));
} catch (InterruptedException e) {
//
e.printStackTrace();
}
Hope this help!
Explanation of error message:
The error message simply says, that the element you want to click on is present, but it is not visible. It could be covered by something or temporary not visible.
There could be many reasons why the element is not visible in the moment of the test. Please re-analyse your page and find proper solution for your case.
Solution for particular case:
In my case, this error occures, when a tooltip of the screen element i just clicked on, was poping over the element I wanted to click next. Defocus was a solution I needed.
Quick solution how to defocus would be to click to some other element in another part of the screen which does "nothing" resp. nothing happens after a click action.
Proper solution would be to call element.blur() on the element poping the tooltip, which would make the tooltip disapear.
I was facing the same problem with clj-webdriver (clojure port of Selenium). I just translated the previous solution to clojure for convenience. You can call this function before doing click or whatever to avoid that problem.
(defn scrollTo
"Scrolls to the position of the given css selector if found"
[q]
(if (exists? q)
(let [ loc (location-once-visible q) jscript (str "window.scrollTo(" (:x loc) "," (:y loc) ")") ]
(execute-script jscript))))
Maybe it's not really clean solution but it works:
try:
el.click()
except WebDriverException as e:
if 'Element is not clickable at point' in e.msg:
self.browser.execute_script(
'$("{sel}").click()'.format(sel=el_selector)
)
else:
raise
I was getting this bug because I tested a hover and then needed to click on the link underneath the tooltip. The solution was to add page.find('.sp-logo').hover before click_link to get the tooltip out of the way.
It's funny, all the time I spent looking at the various responses, no one had tried the obvious, which of course, I hadn't either. If your page has the same id used multiple times, as mine did, ("newButton",) and the one you want is not the first one found, then you will in all likelihood get this error. The easiest thing to do (C#):
var testIt = driver.FindElements(By.Id("newButton"));
Note it's FindElements, not FindElement.
And then test to see how many results came back from the retrieval. If it's the second one, you can then use:
testit[1].Click();
Or get whomever reused ids to fix them.
After testing all mentioned suggestions, nothing worked. I made this code. It works, but is not beautiful
public void click(WebElement element) {
//https://code.google.com/p/selenium/issues/detail?id=2766 (fix)
while(true){
try{
element.click();
break;
}catch (Throwable e){
try {
Thread.sleep(200);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
}
}
public void click(String css) {
//https://code.google.com/p/selenium/issues/detail?id=2766 (fix)
while(true){
try{
driver.findElement(By.cssSelector(css)).click();
break;
}catch (Throwable e){
try {
Thread.sleep(200);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
}
}
I do a kind of brute force of clicks and it works for me.
try:
elem.click()
except:
print "failed to click"
size = elem.size
mid_of_y = int(size["height"])/2
stepts_to_do_to_left = int(size["width"])
while stepts_to_do_to_left > 0:
try:
print stepts_to_do_to_left, mid_of_y
action = webdriver.common.action_chains.ActionChains(driver)
action.move_to_element_with_offset(elem, mid_of_y, stepts_to_do_to_left)
action.click()
action.perform()
print "DONE CLICK"
break
except:
pass
If you have jQuery loaded on the page, you can execute the following javascript command:
"$('#" + element_id + "').click()"
Example using python executor:
driver.execute_script("$('#%s').click()" % element_id)
Try to maximize the browser when you are working with resolutions greater than 1024x768.
driver.manage().window().maximize();