September 2014 - arquillian-issues

[JBoss JIRA] (ARQGRA-459) Allow to load Page Extensions from within WAR deployment

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-459?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-459: ------------------------------ Fix Version/s: 2.1-Tracking > Allow to load Page Extensions from within WAR deployment > -------------------------------------------------------- > > Key: ARQGRA-459 > URL: https://issues.jboss.org/browse/ARQGRA-459 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Lukáš Fryč > Fix For: 2.1-Tracking > > > Allows for debuggability -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-434) Browser screenshooter acts only on @Default Drone

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-434?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-434: ------------------------------ Fix Version/s: 2.1-Tracking > Browser screenshooter acts only on @Default Drone > ------------------------------------------------- > > Key: ARQGRA-434 > URL: https://issues.jboss.org/browse/ARQGRA-434 > Project: Arquillian Graphene > Issue Type: Bug > Components: screenshooter > Affects Versions: 2.1-Tracking > Reporter: Stefan Miklosovic > Assignee: Juraj Húska > Fix For: 2.1-Tracking > > > Browser screenshooter acts only on Drone instances which do not have any qualifier but @Default since current implementation does this check: > {code} > GrapheneContext.getContextFor(Default.class) > {code} > This usage prevents user to use screenshooter in multibrowser scenarios like having Android browser and ordinary Firefox browser in one test class since they can (and must) be differentiated by additional qualifier put on @Drone instances. > Check should be done on instance level and not on qualifier level - meaning we should take context of Drone with ordinary (not mobile) browser which can have any qualifier possible. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-440) Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-440?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-440: ----------------------------------- [~jhuska] does it make sense to upgrade to Drone 2.0 from RichFaces tests perspective? We should really help Drone test the compatibility. At least we could enable a profile that would help test Drone 2.0 compatibility. > Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 > ---------------------------------------------------------- > > Key: ARQGRA-440 > URL: https://issues.jboss.org/browse/ARQGRA-440 > Project: Arquillian Graphene > Issue Type: Task > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj Húska > Fix For: 2.1.0.Alpha2 > > > IMHO we should upgrade to new Drone {{2.0.0.Alpha1}} as well as to Arquillian core {{1.1.4.Final}} in a non stable 2.1.x branch to try compatibility with these versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-460) Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code)

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-460?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-460: ------------------------------ Fix Version/s: 2.1-Tracking > Introduce Graphene.log page extension, than enables to log to browser console (both, from Java and JavaScript code) > ------------------------------------------------------------------------------------------------------------------- > > Key: ARQGRA-460 > URL: https://issues.jboss.org/browse/ARQGRA-460 > Project: Arquillian Graphene > Issue Type: Feature Request > Reporter: Lukáš Fryč > Fix For: 2.1-Tracking > > > Enable services like XHRInterceptor, RequestGuard and XHRHalter to log via Graphene.log. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-440) Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-440?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-440: ------------------------------ Fix Version/s: 2.1.0.Alpha2 > Upgrade Drone to 2.0.0.Alpha1 and Arquillian core to 1.1.4 > ---------------------------------------------------------- > > Key: ARQGRA-440 > URL: https://issues.jboss.org/browse/ARQGRA-440 > Project: Arquillian Graphene > Issue Type: Task > Components: core > Affects Versions: 2.1.0.Alpha1 > Reporter: Juraj Húska > Fix For: 2.1.0.Alpha2 > > > IMHO we should upgrade to new Drone {{2.0.0.Alpha1}} as well as to Arquillian core {{1.1.4.Final}} in a non stable 2.1.x branch to try compatibility with these versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-462) Polish AjaxHalter API

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-462?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-462: ------------------------------ Fix Version/s: 2.1-Tracking > Polish AjaxHalter API > --------------------- > > Key: ARQGRA-462 > URL: https://issues.jboss.org/browse/ARQGRA-462 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: api, core > Affects Versions: 2.1.0.Alpha2 > Reporter: Juraj Húska > Fix For: 2.1-Tracking > > > The API for {{AjaxHalter}} was ported from {{XHRHalter}} in _Graphene1_. > We talked about polishing it based on the community feedback after releasing {{2.1.0.Alpha2}}. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-417: ----------------------------------- Graphene should be configured to do so. > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj Húska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-417: ----------------------------------- This would be very useful for ScreenShooter extension as well. > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj Húska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-417) Support for automatic scrolling to element before its usage

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-417?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-417: ------------------------------ Fix Version/s: 2.1-Tracking > Support for automatic scrolling to element before its usage > ----------------------------------------------------------- > > Key: ARQGRA-417 > URL: https://issues.jboss.org/browse/ARQGRA-417 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.1.Final > Reporter: Juraj Húska > Priority: Minor > Fix For: 2.1-Tracking > > > It would be nice if Graphene supports automatic scrolling of browser window to {{WebElement}} / Page Fragment before its is used. > It can be useful for interactions with various popups web components: contextMenu, tooltip, ... > Those components can not be interacted correctly when they are not in the viewport, and thus one needs to scroll to them manually in his test. > It is often problem in CI environment, where tests run on screens with lower resolution (smaller part of the page fit the browser window, and lot of elements are not in the viewport). > My naive implementation of this would look like: > * intercept all calls to {{WebElements}} and PageFragments root elements > * in the interceptor method get the location of the element by: {{Point location = element.getLocation();}} > * a then scroll to it: {{jsExecutor.executeScript("window.scrollTo("" + location.getX() +", " + location.getY() + ")");}} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-438) Using multiple qualifiers for @Page

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-438?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-438: ----------------------------------- [~smikloso] currently a Graphene handler is injected with static knowledge about the injection point - i.e. it knows what qualifier and what type was requested. You would need to change this knowledge on per-test basis, i.e. before {{test()}} proceeds, you need to set up that SomePage should use @OperatesOnDeployment. TBH I don't believe this feature is enough needed to support it, but I would certainly help you if it is big enough for you that you would like to implement it at own and contribute it to Graphene. > Using multiple qualifiers for @Page > ----------------------------------- > > Key: ARQGRA-438 > URL: https://issues.jboss.org/browse/ARQGRA-438 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.1-Tracking > Reporter: Stefan Miklosovic > Priority: Optional > > In case I have one application deployed to multiple devices (apks to Android) and I use @Page abstraction, I end up with this: > {code} > @Drone @Mobile AndroidDriver mobile; > @Drone @Tablet AndroidDriver tablet; > @Page @Mobile SomePage mobilePage; > @Page @Tablet SomePage tabletPage; > {code} > Event that page is same I have to declare it twice. It could be done as > {code} > @Page @Mobile @Tablet SomePage page; > {code} > In this case, there has to be some distinction between webdrivers and it seems this could be done on deployment level when you use @OperatesOnDeployment annotaion on webdriver injection. In case you have some test method which uses the same @OperatesOnDeployment value, Graphene will inject "right" driver to handle that @Page bean. > Example: > {code} > @Drone @Tablet @OperatesOnDeployment("android_1") AndroidDriver tablet; > @Drone @Mobile @OperatesOnDeployment("android_2") AndroidDriver mobile; > @Page @Tablet @Mobile SomePage somePage; > @Test > @OperatesOnDeployment("android_1") > public void test() > { > somePage will be backed by @Tablet browser > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues September 2014