JDK-8113134 : testLoadUrlWithEncodedSpaces, testLoadUrlWithUnencodedSpaces fail if Skype is running
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: fx2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2011-05-26
  • Updated: 2018-11-12
  • Resolved: 2011-06-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
fx2.0Fixed
Related Reports
Relates :  
JDK-8213541 - WebView does not handle HTTP response without ContentType
Description
Hi Vasiliy,

I think I found the reason - Skype is listening on port 80, if I close it, the tests pass.  So I will just close the Skype when I run the tests :-)

Thank you for your help,
Eva

On 25.5.2011 19:16, Vasiliy Baranov wrote:
> Hi Eva,
>
> Thank you for the problem report.
>
> Unfortunately, I don't have a quick solution for this problem other than ignoring or otherwise disabling these test cases. The failures do look configuration-dependent, but at the same time they seem to uncover problems in shippable code. We will need to look into them thoroughly in order to get to the root cause(s). One complicating factor here is that so far your environment is the only one where these failures are reproducible.
>
> May I ask you a few questions?
>
> What is your operating system?
>
> Are you running a firewall and, if yes, which one?
>
> What happens if you point your browser to http://localhost?
>
> Do you think these failures are a blocking issue and so the tests must be either fixed or removed immediately?
>
> Thank you,
> -- Vasiliy
>
> On 25.05.2011 20:28, Eva Krejcirova wrote:
>> Hi Vasiliy,
>>
>> recently introduced testLoadUrlWithUnencodedSpaces and
>> testLoadUrlWithUnencodedSpaces in
>> javafx-ui-webnode/test/javafx/scene/web/LoadTest.java fail for me on my
>> computer with following error:
>>
>> [junit] java.lang.AssertionError: Unknown network error 0
>> [junit] at
>> javafx.scene.web.LoadListenerClientImpl.describeError(LoadListenerClientImpl.java:66)
>>
>> [junit] at
>> javafx.scene.web.LoadListenerClientImpl$LoadTask.configure(LoadListenerClientImpl.java:107)
>>
>> [junit] at
>> javafx.scene.web.LoadListenerClientImpl.dispatchLoadEvent(LoadListenerClientImpl.java:40)
>>
>> [junit] at
>> com.sun.webpane.platform.WebPage.fireLoadEvent(WebPage.java:2094)
>> [junit] at
>> com.sun.webpane.platform.WebPage.fwkFireLoadEvent(WebPage.java:1914)
>> [junit] at
>> com.sun.webpane.webkit.network.URLProcessor.headerCallback(Native Method)
>> [junit] at
>> com.sun.webpane.webkit.network.URLProcessor.access$100(URLProcessor.java:19)
>>
>> [junit] at
>> com.sun.webpane.webkit.network.URLProcessor$1.run(URLProcessor.java:55)
>> [junit] at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>> [junit] at
>> com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29)
>> [junit] at
>> com.sun.glass.ui.win.WinApplication$1$1.run(WinApplication.java:49)
>> [junit] at java.lang.Thread.run(Thread.java:662)
>> [junit] ------------- ---------------- ---------------
>> [junit] Testcase: testLoadUrlWithEncodedSpaces(javafx.scene.web.LoadTest):
>> FAILED
>> [junit] Waiting timed out
>> [junit] junit.framework.AssertionFailedError: Waiting timed out
>> [junit] at javafx.scene.web.TestBase.wait(TestBase.java:149)
>> [junit] at javafx.scene.web.TestBase.load(TestBase.java:74)
>> [junit] at
>> javafx.scene.web.LoadTest.testLoadUrlWithEncodedSpaces(LoadTest.java:103)
>> [junit]
>> [junit]
>> [junit] Testcase:
>> testLoadUrlWithUnencodedSpaces(javafx.scene.web.LoadTest):
>> FAILED
>>
>> Do you please have any advice on how to solve this? (I suppose that this
>> may be some configuration problem on my side, since the hudson builds
>> are ok).
>>
>> Thanks,
>> Eva
>
Comments
I'd format describeError() differently: String reason = "Unknown error"; then remove the default clause from switch. Why do you think treating zero-length documents as HTML is useful? Content type is used to interpret data, and if there's no data, why is it needed?
01-06-2011
> I'd format describeError() differently: String reason = "Unknown error"; then remove the default clause from switch. OK > Why do you think treating zero-length documents as HTML is useful? This is what Safari and Firefox do, while Chrome and IE do not. You can test this by pointing the browser to http://localhost (while Skype is running) and observing the result. Safari and Firefox will display an empty page, whereas Chrome and IE will display an error page. Actually, there is a difference between Safari and Firefox in that Safari will treat the page as text/html whereas Firefox will treat it as text/plain. There is also a difference between IE and Chrome in that IE will display a "Not Found" error page whereas Chrome will display a generic error page. The latter is probably because the error detected by WebKit in this case has nothing to do with 404 NOT FOUND: the error is in fact called interruptedForPolicyChangeError and is pretty useless to propagate to clients. > Content type is used to interpret data, and if there's no data, why is it needed? Per the spec, the content type is not required if there is no data. And with the fix to describeError() we do not have to default the content type to text/html or text/plain. But I think we better do so for now to mimic the Safari behavior and eliminate at least one possibility for "Unknown error".
01-06-2011
The problem is, when the Skype process listening on port 80 responds to an HTTP request, it does not specify the Content-Type response header. This causes WebKit to generate an error that is not expected by the Java side. This is not happening with the stock CFNetwork library-based WebKit's WinLauncher as CFNetwork defaults the Content-Type to "text/html". Looking into it further.
30-05-2011
I was wondering why this was failing for me when testing, but not failing in Hudson!
26-05-2011