IE 11 has been out just one day as of this posting.
I cannot get an element to go full screen (div or document)
http://msdn.microsoft.com/en-us/library/ie/dn265028
msRequestFullscreen will error 'object does not support this...)
However, the above msdn example will work on passing a target - makeFullScreen(evt.target).
Can I get an div to go fullscreen as in following jquery code?:
var xxx = $('#container');
xxx.msRequestFullscreen();
Or better still: click a button then have a div or the entire document to go fullscreen?
As it stands now, when a click a button, it's the button that goes full screen.
I think this is actually a small misconception of JQuery. JQuery-ing an ID doesn't actually return the element found - it returns a "JQuery object" which allows many actions on that element (or, on a series of elements if you used a class selector)
I don't have IE11 available so I can't test for you, but try this. The [0] should retrieve the element itself.
var xxx = $('#container')[0]; xxx.msRequestFullscreen();
Your code:
var xxx = $('#container');
xxx.msRequestFullscreen();
This is wrong, because you're trying to call a DOM method on a jQuery object.
jQuery calls like $('#container') return jQuery objects. You can do lots of things with these objects, but one thing you can't do is call standard DOM methods. For that, you need an actual DOM object.
jQuery objects contain an array of matching DOM objects, which you can access via [0] for the first one, and [1], etc if there was more than one matching element. So you can do your call by changing your second line as follows:
xxx[0].msRequestFullscreen();
This will call the msRequestFullscreen() on the DOM element rather than the jQuery element, and that should work for you.
In this case, you don't even need jQuery at all, since you're not using any of the jQuery functionality. You could simply use document.getElementById('container') to get the DOM object in the first place rather than the jQuery method. Then you don't need the [0] syntax on the second line because you've already got the DOM object.
Finally, you might want to be careful of course, because this is an IE-specific method; the ms at the front of the name tells you that, which means that your code won't work in other browsers, even if they support the same feature. You need to do it in a cross-browser way. There are some tips on how to do this here: How to make the window full screen with Javascript (stretching all over the screen)
Related
How can I check which element has focus in a Stencil test? I can't use document.activeElement like I would normally do, as it always returns undefined...
Stencil components use Shadow DOM by default and that means that if some element in the Shadow DOM is in focus you can't get it through the normal document.activeElement property. On the other hand, the Shadow DOM host element includes an activeElement property as well (the host element is handled as a different document). You can use the host's activeElement property in your tests, which should hold the focused element inside the Shadow DOM. You can read about that property in MDN.
In some of my projects, when an element is getting focus I add a class to it which helps me to query it later and to add focus styles. This is another way to find elements which are in focus (query for the class).
I came across the same issue and agree with Gil Fink that it seems to be missing from the Stencil Puppeteer abstraction.
I've worked round it by checking that the id of the active element of my components shadow root is the same as the id of the element I expect to have focus. I retrieved the id of the active element using Puppetteers page.$eval(...), e.g.:
const activeElementId = await page.$eval('my-component', (el) => el.shadowRoot.activeElement.id);
const elementThatShouldBeActive = await page.find('my-component >>> #some-id');
expect(activeElementId).toEqual(elementThatShouldBeActive.id);
That works for my context, hopefully it's helpful for you too.
I ended up doing:
const activeElId = await page.evaluate(() => document.activeElement!.id);
I am testing an Electron/React app using Spectron, which uses the WebdriverIO commands API. I would like to test the attributes on some components, but I want to be sure I am testing them only after the component has reloaded.
The normal WebDriverIO wait commands like waitForText() or waitForExist(), wait for some change, but I need to wait until a component redraw has occurred. For example the component will already exist or will already have some text before it is redrawn. This means any test on the text will occur before the redraw, and I won't be testing the new text. Is there a general way to wait for a redraw?
You can use the custom 'waitUntil' command to wait for just about anything. You'd need to figure out what you're waiting for, or how to tell that the component has been redrawn, but it should be possible.
Is there a class name you can tag in to?
Also, the 'waitFor' commands do take negation flags, allowing you to wait for an element to stop existing or stop having text. That might be useful.
Another solution, to this specific question on waiting for changing text, is to use an XPath selector. The XPath language treats an HTML page like a tree, but text, amongst other things, is also a separate node in that tree. Unlike a CSS selector, you can easily select an element based on it's inner text. See this article.
So if my XPath selector uses a text 'predicate', then I can use a standard waitForExist command from the webdriver API.
For example, say my p element, after the redraw, should have the text 'Burgers'. It did exist before the redraw but it had some other text. To only select it when it has the new next:
const selector = '//*p[text()="Burgers"]';
browser.waitForExist(selector);
This is a noobish question but I am getting started with MS Coded UI Tests. And I was wondering if there's a way to find page elements using XPath, instead of the default matching mechanism? What I want to do, is match a parent elements and programmatically navigate down the DOM tree to get the elements I want to work with. This can be easily done with Selenium, but I am not sure how to do it with Coded UI Tests.
Thanks
You should be able to manage navigating an xpath using the UITestControlCollection. Use CodedUI's recorder to get to the top level control, then use GetChildren to navigate your way. Keep in mind that the xpath changes because all the object types are similar, CodedUI's API doesn't distinguish.
Example:
HtmlDocument doc = this.UIYourWindowName.UIYourDocumentName; // mapped control
doc.Find();
UITestControl toline = new UITestControl(doc);
toline.SearchProperties["Id"] = "to_d"; // use the id of the top most control
UITestControlCollection toline1 = toline.GetChildren(); // get the child objects
toline1 = toline1[0].GetChildren(); // xpath: \\ctrl[#id='to_d']\item[0]
toline1 = toline1[0].GetChildren(); // ctrl[]\item[0]\item[0]
// and so on...
I want to use the Watir to click a link that looks like a button attached the image.
I use the following method,but doesn't works:
#browser.div(:id,"NetworkAnalysisTabPanel").div(:index,1).div(:index,1).ul(:index,1).li(:index,1).link(:index,2).click
Note:
#browser.div(:id,"NetworkAnalysisTabPanel").div(:index,1).div(:index,1).ul(:index,1).li(:index,1).link(:index,2).flash
is working fine but click is not working in IE and FF
Link looks like this:
And HMTL like this:
Note: I am able to click on the element using selenium IDE with clickAt method
Try this (not tested):
browser.link(:class => "x-tab-strip-menu").click
If you can flash the link, but click does not do what you want, see this: How to find out which JavaScript events fired?
FYI what you have are links that are using standard background images controlled via CSS magic that keys on the class of the link to know what background to set. That's where the image comes from, and why you don't see it as part of the link in the HTML.
In that control, each tab is a list item element (li) in an unordered list (ul), and each list item has an ID, so that's the easiest way to tell it which tab you are trying to click inside.
Try identifying things starting with the LI that is the tab container, as within that container there is only one instance of each link of a given class. Of the 4 links, only one is without any kind of easy identifier, and if you need to click that one you'd need to use :index, but for the other 3 links using :class ought to work. This should result in code that is less brittle and subject to being broken if the order of tabs changes, or the page is refactored.
#browser.li(:id,"NetworkAnalysisTabPanel__ext-comp-1038").link(:class, "x-tab-strip-menu").click
If the number at the end of the ID is subject to change, you can try a regular expression to match the part you can predict and is unique from the others
#browser.li(:id,/NetworkAnalysisTabPanel__ext-comp-/).link(:class, "x-tab-strip-menu").click
If you can reliably identify the object and use .flash but .click does not seem to do anything, you may have to use .fire_event('onclick') instead or .click.
#browser.li(:id,/NetworkAnalysisTabPanel__ext-comp-/).link(:class, "x-tab-strip-menu").fire_event('onclick')
If that does not work, then you need to start experimenting with likely events that the control might be looking for (which will not necessarily show up in the HTML btw.. it may be in javascript or CSS etc)
UPDATE
This is where having an live example of the control that we can interact with is critical. doing some googling on the class names I was able to find one here and that let me play with it a little, and what I discovered is that it is looking for onmousedown. so, on that site, this works
browser.li(:id, 'TabPanel1__ctl07').link(:class, 'x-tab-strip-menu').fire_event('onmousedown')
Now since those ID's may not be the best identifier, a bit more digging (using .text on the li that holds the tab parts) found me some text, which in a menu like that ought to be unique.. SO, we can change this to make things a bit more robust and clearer as to what tab I'm clicking on (this will also be less subject to breaking if the tabs change around.
browser.li(:text, 'Menu 1').link(:class, 'x-tab-strip-menu').fire_event('onmousedown')
Lastly, since the click is causing client side code to execute, you may need a brief pause (a one or two second sleep) to wait for that portion of the page to re-render etc.
I've been developing a text editor based on SVG, and I'm now trying to
make it so that multiple instances can be instantiated in a single SVG
document. The way I've been trying to achieve this is to wrap the DOM
representation of each text editor instance with a single parent
element (either or ), and then to attach a keypress event
listener to that parent element. The problem I'm running into, though,
is it seems that keypress events are only received by the document
root. Furthermore, for all browser SVG implementations I've tried, the
target, originalTarget, and explicitOriginalTarget event properties,
when they exist, are also set to the document root, so it doesn't
event seem like it's possible to hack a solution by attaching a single
event listener on the document root, and then manually dispatching
events by reading the event's originalTarget property.
So far, I've tested Firefox 3.6, Chromium 9, Opera 11, and Batik
Squiggle 1.7, with the following test case:
http://stuff.echo-flow.com/svg-developers/testEventListener.svg
Only Batik works as expected, with the rect element receiving the
keypress event. In Firefox, target, originalTarget, and
explicitOriginalTarget are all equal to the root element. In Chromium
and Opera, target is set to the root element, and originalTarget and
explicitOriginalTarget are undefined.
Basically, what I'm trying to do is relate a keypress event back to
the element that originally fired it. I think I could probably get
this to work if I used an HTML context and embedded iframes; or, if I
used iframes inside of a foreignObject. But I'm wondering if there's a
cleaner workaround that does not require the use of iframes.
Furthermore, I guess as a worst-case scenario, I could do my own hit
testing by inspecting the clientX/clientY properties of the keypress
event, and comparing that to the bboxes of all text editor group
elements. But once again, this seems very hacky, and I wonder if
there's a better approach.
First, it's better to specify the SVG version and baseProfile you're using in your SVG document.
So far, SVG only support (in the specifications) those events, no key press event. Browsers are a bit ahead the specs, so, lets just assume it's supported.
So, you're using the DOM 3 Event keypress since it doesn't exist in DOM 2 Events.
Looking at keypress event context infos :
Event.target: focused element processing the key event, root element if no suitable input element focused
Focus is not mouse position. In the SVG 1.1 specs, no "focusable" attribute exists, but you can find it in the SVG 2.0 draft.
So Batik use a wrong "keypress event" implementation. You could use the "mouseover event" to know what element you're hovering, or try if the "focusable" attribute is already working on some browsers.
Also, originalTarget and explicitOriginalTarget are Mozilla specific, non standard, that explain your results with other browsers.