[JBoss JIRA] (ARQGRA-398) Release blog for Graphene 2.0.0.Final
by Lukáš Fryč (JIRA)
Lukáš Fryč created ARQGRA-398:
---------------------------------
Summary: Release blog for Graphene 2.0.0.Final
Key: ARQGRA-398
URL: https://issues.jboss.org/browse/ARQGRA-398
Project: Arquillian Graphene
Issue Type: Bug
Affects Versions: 2.0.0.Final
Reporter: Lukáš Fryč
There should be two blogs:
* technical one (announcement), for release (it will be mostly empty)
* a blog accompanying the release which will summarize all the things about project as it went to 2.0.0, roadmap, contribution process , etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQGRA-397) Add support for host (ActiveX) objects
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-397?page=com.atlassian.jira.plugin... ]
Lukáš Fryč commented on ARQGRA-397:
-----------------------------------
It would help if you created a pull request and send it to Github, it's not requirement though (you obviously need a github account created):
https://github.com/arquillian/arquillian-graphene
> Add support for host (ActiveX) objects
> --------------------------------------
>
> Key: ARQGRA-397
> URL: https://issues.jboss.org/browse/ARQGRA-397
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.0.CR2
> Environment: WIn7 x64, msxml3.dll (8.110.7601.17988), msxml6.dll (6.30.7601.17988)
> IE9 (IE9 in compat mode->IE7)
> Richfaces 3.3.4 (Sarissa 0.9.9.3)
> Reporter: Petr Andreev
> Attachments: Graphene.Page.RequestGuard.js.patch, Graphene.xhrInterception.js.patch, test_ActiveXObject.js, test_setTimeout.js
>
>
> Graphene JavaScript RequestGuard interceptors cause failure of all AJAX requests with Richfaces 3 on InternetExplorer with ActiveXObject version of XMLHttpRequest (overriden by Sarissa included in RF3). There are several issues:
> 1. While wrapping the underlying XMLHttpRequest (provided by Sarissa and being actually the ActiveXObject) the InterceptedXMLHttpRequest accesses the response fields of XHR, which is illegal for windows-host objects. I.e. responseText throws an error '#575: This method cannot be called until the send method has been called.' The solution would be to not to read the response properties in constructor of InterceptedXMLHttpRequest since at this phase it makes no sense.
> 2. The bracket- style calls (xhr['send']) on host objects lead to immediate invocation of affected functions without any parameters. Therefore it is impossible to make any reflection-like invocations or checks for existence on them (i.e. if(xhr['send']) or xhr['send'].apply(.....)). The proposed solution is to wrap the host and native objects before 'apply' calls and expand argument list, in that way avoiding failures and ugly browser detection. On the other hand, the invocation of interceptor chain could be refactored (but there could be still problems passing function pointers of host objects: needs to be checked).
> IE9 errors: "#450: Wrong number of arguments or invalid property assignment" or "#87: The parameter is incorrect."
> 3. The scoping of "this" while attaching "onreadystatchange" callback to original (host) XHR is unspecified in contrary to the case with native JS objects. That`s why the interceptors and RF components don`t get notified about completed AJAX request .The solution is simple - just use the wrappers member variable.
> 4. Overriding the "window.setTimeout" method in RequestGuard causes JS error in IE9 + IE compat mode since there are no 'apply' and 'call' functions defined on window`s host object. The solution is to borrow both functions from Function.prototype- works for native objects too.
> Test cases attached (can be ran in http://jsfiddle.net)
> Proposed patches attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQGRA-397) Add support for host (ActiveX) objects
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-397?page=com.atlassian.jira.plugin... ]
Lukáš Fryč commented on ARQGRA-397:
-----------------------------------
Awesome job with investigations and patching this, Petr,
I will look into incorporating your patch to Graphene 2.0.1, as it is regrettably too late 2.0.0.
> Add support for host (ActiveX) objects
> --------------------------------------
>
> Key: ARQGRA-397
> URL: https://issues.jboss.org/browse/ARQGRA-397
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.0.CR2
> Environment: WIn7 x64, msxml3.dll (8.110.7601.17988), msxml6.dll (6.30.7601.17988)
> IE9 (IE9 in compat mode->IE7)
> Richfaces 3.3.4 (Sarissa 0.9.9.3)
> Reporter: Petr Andreev
> Attachments: Graphene.Page.RequestGuard.js.patch, Graphene.xhrInterception.js.patch, test_ActiveXObject.js, test_setTimeout.js
>
>
> Graphene JavaScript RequestGuard interceptors cause failure of all AJAX requests with Richfaces 3 on InternetExplorer with ActiveXObject version of XMLHttpRequest (overriden by Sarissa included in RF3). There are several issues:
> 1. While wrapping the underlying XMLHttpRequest (provided by Sarissa and being actually the ActiveXObject) the InterceptedXMLHttpRequest accesses the response fields of XHR, which is illegal for windows-host objects. I.e. responseText throws an error '#575: This method cannot be called until the send method has been called.' The solution would be to not to read the response properties in constructor of InterceptedXMLHttpRequest since at this phase it makes no sense.
> 2. The bracket- style calls (xhr['send']) on host objects lead to immediate invocation of affected functions without any parameters. Therefore it is impossible to make any reflection-like invocations or checks for existence on them (i.e. if(xhr['send']) or xhr['send'].apply(.....)). The proposed solution is to wrap the host and native objects before 'apply' calls and expand argument list, in that way avoiding failures and ugly browser detection. On the other hand, the invocation of interceptor chain could be refactored (but there could be still problems passing function pointers of host objects: needs to be checked).
> IE9 errors: "#450: Wrong number of arguments or invalid property assignment" or "#87: The parameter is incorrect."
> 3. The scoping of "this" while attaching "onreadystatchange" callback to original (host) XHR is unspecified in contrary to the case with native JS objects. That`s why the interceptors and RF components don`t get notified about completed AJAX request .The solution is simple - just use the wrappers member variable.
> 4. Overriding the "window.setTimeout" method in RequestGuard causes JS error in IE9 + IE compat mode since there are no 'apply' and 'call' functions defined on window`s host object. The solution is to borrow both functions from Function.prototype- works for native objects too.
> Test cases attached (can be ran in http://jsfiddle.net)
> Proposed patches attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1536?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1536:
-----------------------------------
Summary: Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so (was: Provide @StartActivity annotation put on test method to automatically start activity)
> Provide @StartActivity annotation put on test method to automatically start it or use @Location from Graphene to do so
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1536
> URL: https://issues.jboss.org/browse/ARQ-1536
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
>
> Instead of starting activity every time in test method manually, it would be nice to have this possibility:
> {code}
> @Test
> @InSequence(4)
> @OperateOnDeployment("todo-mobile-app")
> public void loginUserInMobile(@ArquillianResource AndroidDevice device) {
> device.getActivityManagerProvider()
> .getActivityManager()
> .startActivity("org.jboss.aerogear.todo.activities.LoginActivity");
> loginMobileFragment.login("john", "123");
> }
> =========================
> @Test
> @InSequence(4)
> @OperateOnDeployment("todo-mobile-app")
> @StartActivity("org.jboss.aerogear.todo.activities.LoginActivity")
> public void loginUserInMobile() {
> loginMobileFragment.login("john", "123");
> }
> {code}
> However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName")
> The problem is, how this translates to Graphene since Droidium starts activities in this manner:
> driver.get("and-activity://" + activityName);
> There is the need to take that "and-activity" string into consideration with @Location annotation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1536) Provide @StartActivity annotation put on test method to automatically start activity
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1536:
--------------------------------------
Summary: Provide @StartActivity annotation put on test method to automatically start activity
Key: ARQ-1536
URL: https://issues.jboss.org/browse/ARQ-1536
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha2
Reporter: Stefan Miklosovic
Instead of starting activity every time in test method manually, it would be nice to have this possibility:
{code}
@Test
@InSequence(4)
@OperateOnDeployment("todo-mobile-app")
public void loginUserInMobile(@ArquillianResource AndroidDevice device) {
device.getActivityManagerProvider()
.getActivityManager()
.startActivity("org.jboss.aerogear.todo.activities.LoginActivity");
loginMobileFragment.login("john", "123");
}
=========================
@Test
@InSequence(4)
@OperateOnDeployment("todo-mobile-app")
@StartActivity("org.jboss.aerogear.todo.activities.LoginActivity")
public void loginUserInMobile() {
loginMobileFragment.login("john", "123");
}
{code}
However, with the possibility to have Graphene page fragments, it would be teoretically possible to have propper page objects as well which mean that we could abstract activity into @Page and specify its @Location("activityName")
The problem is, how this translates to Graphene since Droidium starts activities in this manner:
driver.get("and-activity://" + activityName);
There is the need to take that "and-activity" string into consideration with @Location annotation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months