Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Andreas Leitgeb <avl@logic.at>
Newsgroups: comp.lang.java.programmer
Subject: BasicService.showDocument(...) returns false
Date: Fri, 17 Nov 2017 13:27:07 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <slrnp0totb.774.avl@logic.at>
Reply-To: avl@logic.at
Injection-Date: Fri, 17 Nov 2017 13:27:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2c12693f97ecd2218d84801542c71ef5"; logging-data="26151"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+RwlrSo4ORCz6mtkBF+3V4"
User-Agent: slrn/1.0.2 (Linux)
Cancel-Lock: sha1:TxPZ6OWZYq7iuk4AS43Upp5VyLc=
Xref: csiph.com comp.lang.java.programmer:37670

On client's machines, the method BasicService.showDocument(java.net.URL)
returns false (and shows no effect at all), while on our own machines it
returns true (and does open the requested page).

Are there any quick-hints, as to what might block the opening of webpages?
The same URL copied(from a debugging message in java console) and manually
pasted into the address field of the browser loads just fine.

This is from an old part of the source code that wasn't touched since
2008, and it doesn't yet query whether "isWebBrowserSupported()."
To add that query and get it to run on client's machiens will take
some time, therefore I ask in advance: If further tests reveal that
that method also returned false, then what could be feasible reasons
(and solutions) for that?

PS: yes the customer certainly *wants* these webpages to be opened.
  That's exactly why they click some "Help"-button, which adds the
  context to some base url to serve specific help. If there is some
  setting that disables the openign of URLs, then my "solution" would
  be telling them where to unblock it (if only I knew where).

PPS: the client is running java 8u131 and so do we on our failing 
  attempt to reproduce the failure.