seasidest/parasol

Testing web apps in Smalltalk using Selenium WebDriver.

parasol's Issues

Unexpected response status code 302 while creating web driver session.

In both Pharo 5 & 6.1 on Mac os x 10.36.6 I followed the instructions in the Readme and keep hitting the error in the subject. I have a fix here in a sec but the Session Id code from the 301/302 redirect wasn't working.

The response that causes the error has no body but the headers are:

a ZnHeaders('Cache-Control'->'no-cache' 'Connection'->'close' 'Date'->'Thu, 12 Jul 2018 18:22:01 GMT' 'Expires'->'Thu, 01 Jan 1970 00:00:00 GMT' 'Location'->'http://127.0.0.1:4444/wd/hub/session/1531355270093' 'Server'->'Jetty/5.1.x (Mac OS X/10.13.6 x86_64 java/1.8.0_31' )

The chromedriver version is 2.40.565386

The selenium standalone driver is selenium-server-standalone-3.13.0.jar

Loading parasol and seasidev3.4.7 loops forever

Hi

When trying to load seaside v3.4.7 and parasol I got an endless loop.
I do not really get why in addition the system forces to load Ston and zinc because they are already in the system.

Caching mechanism for drivers does not reset cookies

The class BPWebDriverTestCase caches and reuses BPRemoteWebDriver instances between tests, to prevent having to start the browser for every test. But the caching mechanism doesn't reset cookies, so they carry over from one test to another. The cookies should be cleared (or drivers in which cookies have been set should not be reused).

The Seaside development toolbar is not automatically hidden when running tests

I got a problem because the dev toolbar of Seaside caught an event of an element behind it. Would be cool to disable it for the test app.

Parasol self-tests fail randomly

The Parasol self-tests sometimes suffer from “random” failures. For example, Travis build #58 had one failed test, while the next build had no failing tests (all that changed was the README file).

travis builds for Squeak-5.2 are failing with `MetacelloMCBaselineOfProjectSpec and MetacelloCypressBaselineProjectSpec are not compatible.` error

This particular problem has been fixed with Metacello/metacello#531, presumably Squeak-5.2 is not loading the latest version of Metacello when loading this project ... when and if the Squeak-5.2 image is updated to include the latest Metacello/Metacello commit, the test should start passing again ... see also SeasideSt/Seaside#1229, where Squeak-5.2 was added to the expected failure list - not sure whether Squeak-5.2 is being maintained for Seaside or not

Chromedriver 75 now runs in W3C standard compliant mode by default, breaking compatibility with Parasol

Chromedriver 75 runs in W3C compatibility mode by default [1]. The W3C version protocol of webdriver [2] is not yet implemented in Parasol. The tests should put the 'w3c' chromeoption to false, as long as this protocol is not implemented.

[1] https://chromedriver.storage.googleapis.com/75.0.3770.8/notes.txt
[2] https://www.w3.org/TR/webdriver1/

The #getCapabilities method is broken with selenium v3.6.0

See test output for job 372.1: when sending #getCapabilities a BPUnsupportedCommandException is signaled when using selenium v3.6.0.

Loading in Squeak v5.2 signals an error stating “This package must not be used”

Loading Parasol in Squeak v5.2 fails, with an error stating:

Error: This package must not be used. It was split in 2015 into: WebClient-Seaside-Adatpor and WebClient-Seaside-Tools-Development

See: https://travis-ci.org/SeasideSt/Parasol/jobs/466712494#L757

KeyNotFound: key 'ELEMENT' not found in Dictionary

Running with selenium-server-standalone-3.141.59 and geckodriver-v0.23.0 any attempt to find an element results in the above exception.

I see from the W3 WebDriver spec that:

The web element identifier is the string constant "element-6066-11e4-a52e-4f735466cecf".

Which seems indeed to be what is returned in these cases, yet there are several methods that check for the string 'ELEMENT' instead.

POST /session/56...73/keys did not match a known command

Pharo5.0 (Latest update: #50761)

Metacello new
baseline: 'Parasol';
repository: 'github://SeasideSt/Parasol/repository';
load: 'tests'.

Parasol-Convenience (ThomasCleenewerck.16)
Parasol-Core (JohanBrichau.62)
Parasol-Pharo (JohanBrichau.13)
Parasol-Tests (JohanBrichau.34)

BPMiscTestCase debug: #'testPlatformIs'.

POST /session/56...73/keys did not match a known command
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 09:48:19 -0700'
System info: host: '...', ip: '...', os.name: 'Windows 7', os.arch: 'x86', os.version: '6.1', java.version: '1.8.0_111'
Driver info: org.openqa.selenium.firefox.FirefoxDriver
Capabilities [{rotatable=false, raisesAccessibilityExceptions=false, firefoxOptions={args=[], profile=...=}, appBuildId=20161129173726, version=50.0.2, platform=XP, proxy={}, command_id=1, specificationLevel=0, acceptSslCerts=false, processId=2648, browserVersion=50.0.2, platformVersion=6.1, XULappId={...}, browserName=firefox, takesScreenshot=true, takesElementScreenshot=true, platformName=windows_nt}]
Session ID: 56...73

I see this command in https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol but not in https://www.w3.org/TR/webdriver/. Perhaps we should use https://www.w3.org/TR/webdriver/#element-send-keys.

Testing fails on Pharo 5

Testing fails on Pharo 5, see: https://travis-ci.org/SeasideSt/Parasol/jobs/550959588#L993

The whole job fails, without a test report.

Would be cool to be able to initialize the state of a component at the beginning of a test case.

For example I want to test a paginated table.

In a first test I would like to test the table with few data to get only one page.

In the second test I would like to test the table with multiple pages.

getAttribute: may return nil using chromedriver 91.0.4472.19 or 91.0.4472.101 while earlier versions returned a value

Parasol is affected by a bug introduced in chromedriver 91.0.4472.19 :https://bugs.chromium.org/p/chromium/issues/detail?id=1205107
Although the issue is reportedly fixed in chromedriver 91.0.4472.101, the getAttribute: method still returns nil when trying to retrieve the value of an input field.

More context: https://janmolak.com/chrome-91-might-break-your-tests-507309b9b2cd

Example code fail with latest version of Chrome

OS: MacOS
Pharo version: Pharo5.0 Latest update: #50772
Chrome version: Version 76.0.3809.87 (Official Build) (64-bit)
Chrome Driver version: ChromeDriver 76.0.3809.68

Problem:
When running the Wikipedia example code, it fails at the following line :-

(driver findElementByID: 'searchInput') click.

Error Message: "KeyNotFound: key 'ELEMENT' not found in Dictionary

Automated tests are not run for VisualWorks

The automated tests are currently not run for VisualWorks. I'm not sure whether Parasol still works on VisualWorks or not. I'm not aware of anyone actively using Parasol on VisualWorks.

I don't think smalltalkCI has support for VisualWorks.

Perhaps we should just remove support for VisualWorks (unless someone who wants to maintain the VisualWorks-support package speaks up).

Loading in Squeak fails with error “Name not found: Grease-Core”

See Travis CI job 248.5 for Squeak-4.6: loading failed on “Error: Name not found: Grease-Core”. The same error seems to have occurred in all builds since build 244. In job 243.4, the tests were still run.

waitUntil on BPSeasideWebDriverTestCase

Hi,

I have see two interesting functions :
BPSeasideWebDriverTestCase >> waitUntil:checkEvery:timeoutAfter:
BPSeasideWebDriverTestCase >> waitUntil:checkEvery:timeoutAfter:with:

Why don't move this on parent BPSeasideWebDriverTestCase ?

Fix setup for Pharo 11.0?

Hey, I wanted to try this out but when I evaluate this, I get a KeyError because of ZnZincServerAdaptor?

Metacello new
    baseline: 'Parasol';
    repository: 'github://SeasideSt/Parasol:master/repository';
    load: 'default'.
(Smalltalk at: #ZnZincServerAdaptor) startOn: 8080.

Infinite load loop involving Seaside and Parasol when reloading either project - GemStone only

There is definitely a Metacello project dependency loop between Seaside and Parasol ... Metacello checks for package dependency loops and not out and out project dependency loops --- a deficiency in Metatacello, but Metacello would simply produce an error, much better than infinite loop, but at the end of the day the loop must be broken ... for the purposes of this bug, I will fix the baseline and remove the Parasol to Seaside project dependency for GemStone only - since it is sufficient that Seaside loads Parasol.

BPPharoPlatform>>#handleRequest: contains commented-out code to strip NULL characters from the response

There's some code in the method BPPharoPlatform>>#handleRequest: to strip trailing NULL characters from the response:

Parasol/repository/Parasol-Pharo.package/BPPharoPlatform.class/instance/handleRequest..st

Lines 7 to 8 in c0aa4c2

	"Carsten Haerle: Why is that necessary? Is it possible to have trailing zeros? Not not be necessary."
	"contents := contents copyFrom:1 to: (contents findLast: [:c | c asInteger ~= 0 ])."

Either that can be removed, or it should be re-enabled again. Based on the change done in 83ad7f2, I would say it might still be necessary.

Links to the corresponding Java API documentation are broken

Some of the comments in methods that refer to the documentation of the corresponding Java API method use the old website, for example:

Parasol/repository/Parasol-Core.package/BPRemoteWebDriver.class/instance/findElementByName..st

Line 5 in 03b6b67

http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/remote/RemoteWebDriver.html#findElementByName(java.lang.String)

Fixing this seems to be just be a matter of replacing http://selenium.googlecode.com/svn/trunk/ by https://seleniumhq.github.io/selenium/, and replacing ( and ) by -. For the above example, the new URL is:

https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/remote/RemoteWebDriver.html#findElementByName-java.lang.String-

Filetree repository directory contains metadata files

The “repository” directory (still) uses metadata files. Even when using GitFileTree-MergeDriver, this can cause merging problems. Plus the MergeDriver is, presumably, not used when merging on the GitHub website.

We should probably adopt the metadata-less option that was introduced a while ago.

Parasol testing hangs when using headless Chrome

The cause is this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=880631&q=headless%20about&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Parasol accesses the about: page in the teardown of every test. Hence, we timeout on every test.

Loading Parasol fails due to “Conflict between existing BaselineOfZincHTTPComponents and ConfigurationOfZincHTTPComponents”

Loading Parasol fails, see the Travis build logs for more details, the error is:

MetacelloConflictingProjectError: Load Conflict between existing BaselineOfZincHTTPComponents [baseline] from github://svenvc/zinc:master/repository and ConfigurationOfZincHTTPComponents stable from http://mc.stfx.eu/ZincHTTPComponents

Add support to set the default download path for chrome

Hi,

I have tried to manually set the default download path for chrome using a DesiredCapabilities object:

desiredDriverBrowserCapabilities
  ^ BPDesiredCapabilities chrome
"    setCapability: 'chromeOptions'  << also tried this"
    setCapability: 'goog:chromeOptions'
          to:
            (Dictionary new
                at: 'prefs'
                put:
                  (Dictionary new
                    at: 'download.default_directory'
                    put: '/tmp/testdownloads';
                    at: 'download.prompt_for_download'
                    put: false;
                    at: 'download.directory_upgrade'
                    put: true;
                    yourself);
          yourself);
    yourself

I could not get that to work. I suspect there are a lot of things related to the internals of WebDriver and chromedriver that I'd have to understand better.

If you trawl the web on the topic, you find a lot of references for setting this using the ChromeOptions object .

It would be super if such an object was available in Parasol or even if there was a bit of documentation for how to get this task done with what is available at present.

port to 3.6.0

It seems that at a minimum, the method CharacterCollection>>substrings: seems to be defined in 3 packages: Grease-GemStone-Core and Parasol-GemStone:

==================== Parasol-GemStone (-) --> image (+)  ====================
Item was removed:
- ----- Method: CharacterCollection>>substrings: (in category '*Parasol-GemStone') -----substrings: separators
-   ^ self subStrings: separators!

So not needed in Parasol ... may not be strictly related to 3.6.0, but I'm not finished yet:)

Test BPRemoteWebDriverTestCase>>#testCookies fails in Squeak

The test BPRemoteWebDriverTestCase>>#testCookies fails in Squeak:

https://travis-ci.org/SeasideSt/Parasol/jobs/550887953#L1139

Parasol test framework has no support for dealing with random test failures

Since there is some random failure with tests it would be nice to let the user define a number of retry when a test fail. By default it would be 0 retry but the user could add a method numberOfRetry in his test class to enable it. Thus the CI would not fail randomly often.

I would like have other opinions about that.

endless loop when loading parasol before mdl (or voyage)

I load in my baseline Parasol, voyage, mdl (and other stuff).

I have noticed that I have to load mdl and voyage before parasol to avoid getting an endless loop

could be related with (but I do NOT use GemStone):
#43

I can fix the problem by changing order but I want to report it here.
With the following baseline the endless loop can be reproduced:

baseline: spec
	<baseline>
	spec
		for: #common
		do: [ spec blessing: #baseline.
			spec
				baseline: 'Parasol'
				with: [ spec
						loads: #('core');
						repository: 'github://SeasideSt/Parasol/repository' ].
			spec
				baseline: 'MaterialDesignLite'
				with: [ spec repository: 'github://DuneSt/MaterialDesignLite:v2.2.4/src' ] ]

New versions of chromedriver seem pegged to specific Chrome versions

Newer versions of chromedriver seem to be pegged to specific Chrome versions. While v2.41 of chromedriver seems to allow using Chrome 75.0.3770.100; the newer v2.45 refuses to create a session, returning an error instead saying “Chrome version must be between 70 and 73”.

Implication: we may need to update chromedriver more often, or specify the version of Chrome to use in the “.travis.yml” file as well.

Support for checking running XMLHttpRequests

Feature request (Johan here, writing with Koen's account)

Scenario: running Seaside tests that perform jQuery ajax requests require to wait until the browser's running XMLHttpRequests are done. Having native support for this in Parasol would be helpful.

Error message from Selenium 4 may not be in W3C format, crashing Parasol when it occurs

Using Selenium 4, the error message that is returned may follow a different format than the W3C protocol. For example, the following can be returned when trying to delete a session that was already closed:

{
  "value": "\u002fsession\u002fc8f703018cf377e41f5a94584d3e4bab",
  "message": "Unable to execute request for an existing session: Unable to find session with ID: c8f703018cf377e41f5a94584d3e4bab\nBuild info: version: '4.1.2', revision: '9a5a329c5a'\n ......",
  "error": "org.openqa.selenium.NoSuchSessionException"
}

In W3C spec, the 'error' and 'message' attributes should have been nested inside the 'value' attribute. (see https://www.w3.org/TR/webdriver/#errors).

Since this crashes the error handling, a workaround in Parasol is needed. It is unclear to me why it occurs for now.