I was wondering if anybody can tell me the right way to check the node type of YUI3 node instance. ie node.nodeType==3 for text node etc.
Y.one('body').nodeType; //does not work
Thank you
OK I found out the solution. It's a bit ugly, but... Any property of an original DOM Node (ie. nodeType,NodeValue etc.) can be retrieved by calling get method:
var type=Y.one("body").get('nodeType');
alert (type); //1 for element(3 for text etc)
This is very useful for iterating over text/element nodes.
Hope this helps someone!
Related
My HTML-Page contains (among other stuff) this bit:
<ol id="links">
<li id="links_1">stackoverflow</li>
</ol>
In my code to test the page, I then do:
el←FindElementById'links_1'
(ACTIONS.MoveToElement el).Build.Perform
and this crashes with
EXCEPTION: stale element reference: element is not attached to the page document
(Session info: chrome=81.0.4044.129)
However, this error doesn't seem to be justified, as the element is still alive:
el.Displayed
1
el.Text
stackoverflow
el.Location
{X=56,Y=282}
How can I fix this problem?
(The environment is APL. I've left out a few APL-details here because I feared they might be avoidable "distraction" from the core-issue)
During my research before posting, I saw the question stale element reference: element is not attached to the page document but it doesn't seem to apply:
as shown, I'm doing the FindElementById and access it immediately after finding it. The DOM doesn't change, page is static.
explanations about it no longer being part of the DOM do not apply: it is found and, as I attempted to show, I can access properties such as Displayed or Text.
I also went through the reference, but this explanation did not help.
Also, there is no looping going on and nothing changes the page. It's really straightforward: GoToUrl * Find * MoveToElement.
I removed the chromedriver-tag, as I can repro this with Firefox and geckodriver. However, with geckodriver, I get "EXCEPTION: Web element reference not seen before:" when I do MoveToElement - but I can do el.Click and access its properties in exactly the same way that as with Chrome.
Update: a coworker investigated this a bit deeper (beyond my comfort zone) and found that before throwing this "stale exception", there is (I'm not sure how to word this properly and where exactly it occurred) a 404-exception. I just know 404 as an HTTP Status-code - that's all it means to me. But clearly the browser was not asked to navigate anywhere, so I can't be related to an HTTP404. Does that perhaps ring some bells with anyone more familiar with the internals of WebDriver?
This was a complex and multi-layered problem, but when I finally removed all layers - it worked!
The key-factor which caused this problem:
due to a fault in the way I had written the test caused it to be executed twice - and the 2nd run always exposed the problem.
I had instantiated ACTIONS in the test-framework and was not aware of a critical feature: it continuously builds a chain of actions, any Build.Perform..-steps just added to that. Solution: create separate instances of every run (possibly, since it's fairly lightweight) or call ACTIONS.Reset(requires WebDriver4). I've never had issues with WD4 (although it still is in alpha) - but this gave the ultimate reason to switch!
I am creating a suite of tests (using Geb/Spock) for a web site. In one of them, the element I want to access is on the top of the page, so, to make sure that is visible, I want to scroll to the top of the page.
The command I am using is:
browser.js.exec('window.scrollTo(0, 0);')
or variations of it like
js.exec('window.scrollTo(0, 0);')
or other alternative like:
js.exec('window.scrollBy(0, -250);')
None of them makes the page scroll up, and when executing I get the following error (it is the only error, no other feedback). The error message using the other options listed above is identical (other than the command itself):
Condition not satisfied:
browser.js.exec('window.scrollTo(0, 0);')
| | |
| | null
| geb.js.JavascriptInterface#4019094f
geb.Browser#3dcac33e
at UserCreatesCompany.Go to Home Page and click on the log to
GitHub button as user User1(UserCreatesCompany.groovy:170)
I can not interpret the message that 'exec' is null. What exactly it means?
To make things more interesting, at the end of this script I am running the following cleanup procedure
js.exec('window.scrollTo(0, document.body.scrollHeight);')
DeleteButton.click()
$("button",'data-automation-id':"button-modal-yes").click()
}
and that works well: the page scrolls down. So, does not seem a problem about some missing library.
Any suggestion of what I may be doing wrong?
The version of the different components I am using is:
groovyVersion = '2.5.4'
gebVersion = '2.3'
seleniumVersion = '3.141.59'
chromeDriverVersion = '2.45'
First of all, you should not need to ever manually scroll the page to make elements visible - Selenium WebDriver which is underpinning Geb will do that for you automatically as soon as you start interacting (clicking, setting value, etc) with content.
Secondly, the failure you are getting is a failed assertion coming from a statement in an automatically asserted (then: or expect:) Spock block. It feels to me that you don't understand a concept which is core to Spock and therefore you should read about it in the manual first. It should make the failure you're getting clearer.
Thanks for the answer. Clearly: I was not fully aware of the different constrains the different blocks impose on what is executable or not. The manual is pretty clear once you have stumbled!
I am intrigued by your first assertion pointing that Selenium WebDriver will move to the element as soon as I interact with it. That was my understanding but it was not working. I made sure the element in question had a unique identifier, but still, it was not able to found it if the element had to be found by scrolling up. On the other hand it worked smoothly when locating the element WebDriver scrolled the page down.
Thanks again for the explanation. I have learn something new today!
Dojo has a basic issue, amongst other things... with its dojo.dnd.move class. The issue which you can see here:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojo/tests/dnd/test_parent_constraints.html
Is that when you click on a node, and start dragging, the node itself jumps. It actually moves its position. This is extremely problematic and I was wondering if anyone has seen this happen before.
I am creating an application that requires the moving of nodes but it needs to be precise and thus can't have the initial jump.
Any help would be greatly appreciated.
This is caused by the following highlighted code in Mover.js:
https://github.com/dojo/dojo/blob/master/dnd/Mover.js#L91-92
The odd thing is, based on the comments, it seems like this code is causing the very problem it aims to prevent.
That said, if your body has padding: 0 applied to its style, this code shouldn't affect you. (You can test it on that test page by running document.body.style.padding = "0" in the console before dragging.)
You might want to enter a ticket on the Dojo bug tracker at http://bugs.dojotoolkit.org (or maybe search and see if one has already been entered for it).
I'm currently working on an Extension for Safari 5 and I want to run a listener function whenever Settings changes are made. Apple provides an example for that, but it doesn't work for me. I currently have this listener function in my global html file:
function numberChanged()
{
if(event.key == "number")
alert("Number has changed!");
}
safari.self.addEventListener("change", numberChanged, false);
I hope somebody can help me. Does somebody know what I'm doing wrong?
I believe that you need to include ‘event’ as a parameter in your function so it looks like this:
function numberChanged(event)
{
if(event.key == "number")
alert("Number has changed!");
}
however, that said, it’s not working properly for me either (with or without the param), so I might be wrong. Interestingly, every time I change a field or click a button on this stackoverflow form, my alert (similar to yours) IS firing, even though I did not change my setting. totally weird.
update: I got it working, finally. The example that apple provides is just wrong. So there are two parts to the answer. I gave the first part above — you do need to add ‘event’ as a parameter to your function. the second part is that the addeventlistener has to be done on the settings object and not, as apple shows you, using ‘self’ from the global.html page. so the working call would look like this for you:
safari.extension.settings.addEventListener("change",numberChanged,false);
Thanks to everyone in advance -
So I have been banging on this issue for quite a while now and have burned through all my options. My current approach to canceling css requests is with nsIRequest.cancel inside of nsIWebProgressListener.onStateChange. This works most of the time, except when things are a little laggy a few will slip through and jump out of the loadgroup before I can get to them. This is obviously a dirty solution.
I have read through the following links to try and get a better idea of how to disable css before a nsIRequest is created...no dice.
https://developer.mozilla.org/en/Document_Loading_-_From_Load_Start_to_Finding_a_Handler
https://developer.mozilla.org/en/The_life_of_an_HTML_HTTP_request
https://developer.mozilla.org/en/Bird's_Eye_View_of_the_Mozilla_Framework
How do I disable css via presentation objects/interfaces? Is this possible? Inside of nsIDocShell there are a few attributes that kind of imply you can disable css via the browsers docshell - allowPlugins, allowJavascript, allowMetaRedirects, allowSubframes, allowImages.
Any suggestions?
Thanks,
Sam
The menu option that disables style sheets uses a function
setStyleDisabled(true)
so you probably can just call this function whenever new browser tab is created. Style sheets are still requested from server, but not applied. This function is not very sophisticated and doesn't mess with nsIRequest, source:
function setStyleDisabled(disabled) {
getMarkupDocumentViewer().authorStyleDisabled = disabled;
}
Digging in Web Developer Toolbar source code I have noticed that their "disable stylesheets" function loops trough all document.styleSheets and sets the disabled property to true, like:
/* if DOM content is loaded */
var sheets = document.styleSheets;
for(var i in sheets){ sheets[i].disabled = true; }
So if the key is to not apply CSS to pages, one of the above solutions should work. But if you really need to stop style sheets from being downloaded from servers, I'm affraid nsIRequest interception is your only option.
Set permissions.default.stylesheet to 2 and voilà!
You can actually use the permissions manager to block or allow stylesheets on a host-by-host basis.
Unfortunately there doesn't seem to be a simple flag like allowImages. The bugzilla adding for that is https://bugzilla.mozilla.org/show_bug.cgi?id=340746. You can now vote for it using the new bugzilla voting functionality. You can also add yourself to the CC list to be notified if anyone ever works on it.
A related request is to just give us basic HTML parsing support, which may be what you are trying to do. Unfortunately that isn't supported yet either, but you can vote/track the bugzilla for that at https://bugzilla.mozilla.org/show_bug.cgi?id=102699.
So the only workable solution seems to be some sort of interception as #pawal suggests. Here is a link that talks about the basics of interception to at least get you/us started https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads. It lists several options that I list below.
These first few seem to just be at the page/document level so I don't think they help:
Load Events (addEventListener load)
Web Progress Listeners (nsIWebProgressListener) - I tried this approach, it only seems to be called for the page itself, not for content within the page.
Document Loader Service - A global version of nsIWebProgressListener so I think it has the same problem (page level only)
That leaves two others I have not tried yet. They work globally so you would need to filter them to just the browser/pages you care about.
HTTP Observers - Seems like it might work, need to verify it calls back for CSS
Content Policy - Seems like the best option to me since it explicitly is called for CSS, someday I hope to try it :)