[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426607#comment-16426607
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/269
  
I just tested a bit around and I would suggest the following changes:

* Drop the support for minor version in exchange for a full version String 
(11.0, 3.5.8, 4.0b4a)
* Change the implementation to yauaa - I also played around a bit and found 
some not correctly resolved version numbers (the browsers are all detected 
correctly) https://github.com/nielsbasjes/yauaa/issues/75
* Change the UserAgent enum to not handle excludes, but only browser names

If the issue is fixed I can provide a PR.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426777#comment-16426777
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/269
  
Guys I get it, there are many good solutions to choose from, but why should 
we make Wicket dependent on anyone of them?

https://github.com/nielsbasjes/yauaa looks good, but do users really need 
assistance for this?

`UserAgent  userAgent = analyzer.parse(new 
WebClientInfo(requestCycle).getUserAgent());`


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426818#comment-16426818
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/269
  
In my opinion and because of such a big pool of browsers I would say yes.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6546) CssContentHeaderItem comments CSS code with HTML comments

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427196#comment-16427196
 ] 

ASF GitHub Bot commented on WICKET-6546:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/274


> CssContentHeaderItem comments CSS code with HTML comments
> -
>
> Key: WICKET-6546
> URL: https://issues.apache.org/jira/browse/WICKET-6546
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 6.24.0, 6.29.0
>Reporter: Robert Niestroj
>Assignee: Maxim Solodovnik
>Priority: Minor
> Attachments: wicket6546 (2).zip
>
>
> CssContentHeaderItem wraps the passed CSS in HTML comments thus rendering 
> invalid markup.
> Example code:
>  
> {code:java}
> @Override
> public void renderHead(Component component, IHeaderResponse response) {
>    super.renderHead(component, response);
>    response.render(CssContentHeaderItem.forCSS(".select2-container--open 
> {z-index: 10;}", "select2-mod", ""));
> }
> {code}
> Renders:
>  
> {code:java}
> 
> 
> {code}
> The HTML comments in the CSS make the response invalid and in the browser you 
> get a XML Parsing Error - Not Well Formed.
>  
> It should not render this invalid html comments in CSS.
> Looking at the source code i think the error is in the CssUtils class: 
> https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426055#comment-16426055
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/269
  
I also looked a bit around and stumbled over Apache DeviceMap which has 
been moved into the Attic and from the Attic 
(http://attic.apache.org/projects/devicemap.html) I followed the link to 
https://github.com/nielsbasjes/yauaa which seems to be maintained.

@kbachl - I understand your suggestion to remove it because of reliability, 
but I would keep the functionality with the hint that there might be some not 
supported browsers which is better than no detection.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435029#comment-16435029
 ] 

ASF GitHub Bot commented on WICKET-6544:


GitHub user klopfdreh opened a pull request:

https://github.com/apache/wicket/pull/275

[WICKET-6544] mobile browser detection is improved (with YAUAA)

Hi all,

here my 5 cent regarding the browser detection with 
https://github.com/nielsbasjes/yauaa

you have to extend the test to see the real benefit.

kind regards

Tobias

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/klopfdreh/wicket browser_version_detection

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/275.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #275


commit 96bab261b5c9e96393737444ac9601eda97ef7bc
Author: Tobias Soloschenko 
Date:   2018-04-12T07:05:19Z

Browser / Version detection




> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435031#comment-16435031
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/269
  
See my suggestion over here: https://github.com/apache/wicket/pull/269


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436321#comment-16436321
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user svenmeier commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181224559
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -46,14 +46,20 @@
 
/**
 * The user agent string from the User-Agent header, app. 
Theoretically, this might differ from
-* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property, which is
-* not set until an actual reply from a browser (e.g. using {@link 
BrowserInfoPage} is set.
+* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property,
+* which is not set until an actual reply from a browser (e.g. using 
{@link BrowserInfoPage} is
+* set.
 */
private final String userAgent;
 
/** Client properties object. */
private final ClientProperties properties;
 
+   private final static UserAgentAnalyzer UAA = 
UserAgentAnalyzer.newBuilder()
--- End diff --

UserAgentAnalyzer isn't reentrant. Since it is expensive to create one, 
instances have to be pooled.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429381#comment-16429381
 ] 

ASF GitHub Bot commented on WICKET-6321:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/273
  
@kbachl all jQuery 3.x should work fine. If you think Wicket should switch 
to v3 as default, you an open anothe issue. For me v2 is fine though.


> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: CORS.zip, wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436902#comment-16436902
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293591
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

I would rather have all these as individual tests, to be able to see which 
one was failed
And run all of them regardless failure state of others


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436912#comment-16436912
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181295733
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

Yes that is true, but I think if you change the code / the browser 
detection you are going to investigate why the test is failing and fix the 
integration as long as every test is back working again.

@BeforeClass is not working, because WicketTestCase and at this stage no 
Application is attached to the main thread.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436905#comment-16436905
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293918
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

You can move init to `@BeforeClass` .


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436904#comment-16436904
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293718
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

You will see if something fails in the test results btw.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436903#comment-16436903
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293658
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

This might slow down the test execution because of the init of YAUAA - try 
it out.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436917#comment-16436917
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181297750
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

Will try to provide patch later tonight
Have to do day time job right now :(


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436969#comment-16436969
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user svenmeier commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181308489
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -46,14 +46,20 @@
 
/**
 * The user agent string from the User-Agent header, app. 
Theoretically, this might differ from
-* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property, which is
-* not set until an actual reply from a browser (e.g. using {@link 
BrowserInfoPage} is set.
+* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property,
+* which is not set until an actual reply from a browser (e.g. using 
{@link BrowserInfoPage} is
+* set.
 */
private final String userAgent;
 
/** Client properties object. */
private final ClientProperties properties;
 
+   private final static UserAgentAnalyzer UAA = 
UserAgentAnalyzer.newBuilder()
--- End diff --

UserAgentAnalyzer#parse(UserAgent) is synchronized, please check its code. 
This is even mentioned on the project home page.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436915#comment-16436915
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181296712
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

May you have any other good idea to keep the tests individual.

Just send a patch to me if something would fit the requirement and I am 
going to integrate it.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436937#comment-16436937
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181303063
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

Hehe me too  - no hurry, because I think this is going to be released in a 
further version.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436899#comment-16436899
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293318
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -147,6 +149,93 @@ private String getUserAgentStringLc()
return (getUserAgent() != null) ? getUserAgent().toLowerCase() 
: "";
}
 
+   /**
+* Initializes the {@link WebClientInfo} user agent detection. This can 
be overridden to choose
+* a different detection as YAUAA 
(https://github.com/nielsbasjes/yauaa) - if you do so, you
+* might exclude the maven dependency from your project in favor of a 
different framework.
+*/
+   public void initialize()
+   {
+   UserAgentAnalyzer userAgentAnalyzer = 
Application.get().getMetaData(UAA_META_DATA_KEY);
+   if (userAgentAnalyzer == null)
+   {
+   userAgentAnalyzer = UserAgentAnalyzer.newBuilder()
+   .hideMatcherLoadStats()
+   .withCache(25000)
+   .build();
+   Application.get().setMetaData(UAA_META_DATA_KEY, 
userAgentAnalyzer);
+   }
+   detectBrowserProperties(userAgentAnalyzer);
+   }
+
+   /**
+* Detects browser properties like versions or the type of the browser 
and applies them to the
+* {@link ClientProperties}, override this method if there are errors 
within the browser /
+* version detection due to newer browsers
+* 
+* @param userAgentAnalyzer
+*the user agent analyzer to detect browsers and versions
+*/
+   protected void detectBrowserProperties(UserAgentAnalyzer 
userAgentAnalyzer)
+   {
+
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
userAgentAnalyzer
+   .parse(getUserAgent());
+   String userAgentName = parsedUserAgent.getValue("AgentName");
+
+   // Konqueror
+   
properties.setBrowserKonqueror(UserAgent.KONQUEROR.getUaStrings().contains(userAgentName));
+
+   // Chrome
+   
properties.setBrowserChrome(UserAgent.CHROME.getUaStrings().contains(userAgentName));
+
+   // Edge
+   
properties.setBrowserEdge(UserAgent.EDGE.getUaStrings().contains(userAgentName));
+
+   // Safari
+   
properties.setBrowserSafari(UserAgent.SAFARI.getUaStrings().contains(userAgentName));
+
+   // Opera
+   
properties.setBrowserOpera(UserAgent.OPERA.getUaStrings().contains(userAgentName));
+
+   // Internet Explorer
+   properties.setBrowserInternetExplorer(
+   
UserAgent.INTERNET_EXPLORER.getUaStrings().contains(userAgentName));
+
+   // FireFox
+   boolean isFireFox = UserAgent.FIREFOX.getUaStrings()
+   .contains(parsedUserAgent.getValue("AgentName"));
--- End diff --

`userAgentName`


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> 

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436900#comment-16436900
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181293350
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -147,6 +149,93 @@ private String getUserAgentStringLc()
return (getUserAgent() != null) ? getUserAgent().toLowerCase() 
: "";
}
 
+   /**
+* Initializes the {@link WebClientInfo} user agent detection. This can 
be overridden to choose
+* a different detection as YAUAA 
(https://github.com/nielsbasjes/yauaa) - if you do so, you
+* might exclude the maven dependency from your project in favor of a 
different framework.
+*/
+   public void initialize()
+   {
+   UserAgentAnalyzer userAgentAnalyzer = 
Application.get().getMetaData(UAA_META_DATA_KEY);
+   if (userAgentAnalyzer == null)
+   {
+   userAgentAnalyzer = UserAgentAnalyzer.newBuilder()
+   .hideMatcherLoadStats()
+   .withCache(25000)
+   .build();
+   Application.get().setMetaData(UAA_META_DATA_KEY, 
userAgentAnalyzer);
+   }
+   detectBrowserProperties(userAgentAnalyzer);
+   }
+
+   /**
+* Detects browser properties like versions or the type of the browser 
and applies them to the
+* {@link ClientProperties}, override this method if there are errors 
within the browser /
+* version detection due to newer browsers
+* 
+* @param userAgentAnalyzer
+*the user agent analyzer to detect browsers and versions
+*/
+   protected void detectBrowserProperties(UserAgentAnalyzer 
userAgentAnalyzer)
+   {
+
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
userAgentAnalyzer
+   .parse(getUserAgent());
+   String userAgentName = parsedUserAgent.getValue("AgentName");
+
+   // Konqueror
+   
properties.setBrowserKonqueror(UserAgent.KONQUEROR.getUaStrings().contains(userAgentName));
+
+   // Chrome
+   
properties.setBrowserChrome(UserAgent.CHROME.getUaStrings().contains(userAgentName));
+
+   // Edge
+   
properties.setBrowserEdge(UserAgent.EDGE.getUaStrings().contains(userAgentName));
+
+   // Safari
+   
properties.setBrowserSafari(UserAgent.SAFARI.getUaStrings().contains(userAgentName));
+
+   // Opera
+   
properties.setBrowserOpera(UserAgent.OPERA.getUaStrings().contains(userAgentName));
+
+   // Internet Explorer
+   properties.setBrowserInternetExplorer(
+   
UserAgent.INTERNET_EXPLORER.getUaStrings().contains(userAgentName));
+
+   // FireFox
+   boolean isFireFox = UserAgent.FIREFOX.getUaStrings()
+   .contains(parsedUserAgent.getValue("AgentName"));
+   if (isFireFox)
+   {
+   properties.setBrowserMozillaFirefox(true);
+   properties.setBrowserMozilla(true);
+   }
+   else
+   {
+   properties.setBrowserMozilla(
+   
UserAgent.MOZILLA.getUaStrings().contains(parsedUserAgent.getValue("AgentName")));
--- End diff --

`userAgentName`


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436897#comment-16436897
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/275
  
Following changes have been made:

* The init() method has been changed into gatherExtendedInfo() which is 
only be executed if 
org.apache.wicket.settings.RequestCycleSettings.setGatherExtendedBrowserInfo(boolean)
 is set to true
* MetaDataKey has been used to initialize YAUAA
* All browser specific methods have been moved into detectBrowserProperties
* gatherExtendedInfo / detectBrowserProperties are protected / public so 
that the user may override them


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436907#comment-16436907
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181294275
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

All subsequent lines will not be executed in case of failure  


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436780#comment-16436780
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181282823
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -193,165 +198,117 @@ protected String getRemoteAddr(RequestCycle 
requestCycle)
 */
private void init()
{
-   setInternetExplorerProperties();
-   setOperaProperties();
-   setMozillaProperties();
-   setKonquerorProperties();
-   setChromeProperties();
-   setEdgeProperties();
-   setSafariProperties();
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
UAA.parse(getUserAgent());
+   setInternetExplorerProperties(parsedUserAgent);
+   setKonquerorProperties(parsedUserAgent);
+   setMozillaProperties(parsedUserAgent);
+   setOperaProperties(parsedUserAgent);
+   setChromeProperties(parsedUserAgent);
+   setEdgeProperties(parsedUserAgent);
+   setSafariProperties(parsedUserAgent);
--- End diff --

can be replaced with
String agent = parsedUserAgent.getValue("AgentName");

properties.setBrowserKonqueror(UserAgent.KONQUEROR.getUaStrings().contains(agent));

properties.setBrowserChrome(UserAgent.CHROME.getUaStrings().contains(agent));
.
setBrowserVersion(parsedUserAgent);


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436819#comment-16436819
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181286646
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -46,14 +46,20 @@
 
/**
 * The user agent string from the User-Agent header, app. 
Theoretically, this might differ from
-* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property, which is
-* not set until an actual reply from a browser (e.g. using {@link 
BrowserInfoPage} is set.
+* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property,
+* which is not set until an actual reply from a browser (e.g. using 
{@link BrowserInfoPage} is
+* set.
 */
private final String userAgent;
 
/** Client properties object. */
private final ClientProperties properties;
 
+   private final static UserAgentAnalyzer UAA = 
UserAgentAnalyzer.newBuilder()
--- End diff --

The initialization is expensive, but the UserAgentAnalyzer is thread safe 
so it can be reused. Maybe we are able to use MetaDataKey


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436810#comment-16436810
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181286230
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -193,165 +198,117 @@ protected String getRemoteAddr(RequestCycle 
requestCycle)
 */
private void init()
{
-   setInternetExplorerProperties();
-   setOperaProperties();
-   setMozillaProperties();
-   setKonquerorProperties();
-   setChromeProperties();
-   setEdgeProperties();
-   setSafariProperties();
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
UAA.parse(getUserAgent());
+   setInternetExplorerProperties(parsedUserAgent);
+   setKonquerorProperties(parsedUserAgent);
+   setMozillaProperties(parsedUserAgent);
+   setOperaProperties(parsedUserAgent);
+   setChromeProperties(parsedUserAgent);
+   setEdgeProperties(parsedUserAgent);
+   setSafariProperties(parsedUserAgent);
--- End diff --

Hi @solomax - yes indeed - it was due to the refactoring and those methods 
were present before - I just refactored them.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437040#comment-16437040
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181328485
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -46,14 +46,20 @@
 
/**
 * The user agent string from the User-Agent header, app. 
Theoretically, this might differ from
-* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property, which is
-* not set until an actual reply from a browser (e.g. using {@link 
BrowserInfoPage} is set.
+* {@link 
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()} 
property,
+* which is not set until an actual reply from a browser (e.g. using 
{@link BrowserInfoPage} is
+* set.
 */
private final String userAgent;
 
/** Client properties object. */
private final ClientProperties properties;
 
+   private final static UserAgentAnalyzer UAA = 
UserAgentAnalyzer.newBuilder()
--- End diff --

Have a look at the recent changes. A lot of stuff changed already and I 
think it is ok like it is now (except the tests)


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436776#comment-16436776
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r181282313
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -193,165 +198,117 @@ protected String getRemoteAddr(RequestCycle 
requestCycle)
 */
private void init()
{
-   setInternetExplorerProperties();
-   setOperaProperties();
-   setMozillaProperties();
-   setKonquerorProperties();
-   setChromeProperties();
-   setEdgeProperties();
-   setSafariProperties();
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
UAA.parse(getUserAgent());
+   setInternetExplorerProperties(parsedUserAgent);
+   setKonquerorProperties(parsedUserAgent);
+   setMozillaProperties(parsedUserAgent);
+   setOperaProperties(parsedUserAgent);
+   setChromeProperties(parsedUserAgent);
+   setEdgeProperties(parsedUserAgent);
+   setSafariProperties(parsedUserAgent);
--- End diff --

All these methods looks very much the same 


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428647#comment-16428647
 ] 

ASF GitHub Bot commented on WICKET-6321:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/273
  
@tremel thanks for your usage example.

It seems to me we're mixing at least three topics in this pull request:
- JavaScriptReferenceHeaderItem needs integrity and and crossOrigin ... fine
- JavaScriptUtils#writeJavaScriptUrl() is getting to many parameters, maybe 
an attribute map can help here?
- references cannot alter the attributes of their headerItem (besides the 
url of course): defer, async, charset and now integrity and crossOrigin

IMHO we should solve the last issue separately and uniformly, i.e. not 
IntegrityAttributed but maybe a broader interface for all attributes or just a 
callback that allows the reference to alter the headerItem.
For now you could use an IHeaderResponseDecorator to set the attributes.


> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: CORS.zip, wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445402#comment-16445402
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182962256
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/IMetadataContext.java 
---
@@ -0,0 +1,10 @@
+package org.apache.wicket;
+
+/**
+ * @author Jezza
+ */
+public interface IMetadataContext {
--- End diff --

I also have doubts about the interface name.
If anyone has a better suggestion, I'd be happy to swap it out.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445418#comment-16445418
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user martin-g commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182965042
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/IMetadataContext.java 
---
@@ -0,0 +1,10 @@
+package org.apache.wicket;
+
+/**
+ * @author Jezza
+ */
+public interface IMetadataContext {
--- End diff --

Javadoc would be nice!


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445419#comment-16445419
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user martin-g commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182965271
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/Session.java ---
@@ -422,6 +422,7 @@ public Locale getLocale()
 * @return The metadata
 * @see MetaDataKey
 */
+   @Override
public synchronized final  M getMetaData(final 
MetaDataKey key)
--- End diff --

Why in Application you moved `synchronized` in the method body and here it 
stays as before ? Is there any difference between the implementations ?


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445447#comment-16445447
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user martin-g commented on the issue:

https://github.com/apache/wicket/pull/276
  
Cool!

Please just add Javadoc about the `tparam`s of IMetadataContext!
LGTM!


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445439#comment-16445439
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182967962
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/Session.java ---
@@ -422,6 +422,7 @@ public Locale getLocale()
 * @return The metadata
 * @see MetaDataKey
 */
+   @Override
public synchronized final  M getMetaData(final 
MetaDataKey key)
--- End diff --

There's no practical difference with implementation, but I had to move it 
because it was clashing with the signature from the interface. 


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445449#comment-16445449
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on the issue:

https://github.com/apache/wicket/pull/276
  
Added some javadoc with some barebones explanation.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445504#comment-16445504
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r182987156
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
 ---
@@ -143,215 +150,133 @@ private String getUserAgentStringLc()
}
 
/**
-* When using ProxyPass, requestCycle().getHttpServletRequest(). 
getRemoteAddr() returns the IP
-* of the machine forwarding the request. In order to maintain the 
clients ip address, the
-* server places it in the http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers;>X-Forwarded-For
-* Header.
-*
-* Proxies may also mask the original client IP with tokens like 
"hidden" or "unknown".
-* If so, the last proxy ip address is returned.
-*
-* @param requestCycle
-*the request cycle
-* @return remoteAddr IP address of the client, using the 
X-Forwarded-For header and defaulting
-* to: getHttpServletRequest().getRemoteAddr()
+* Initializes the {@link WebClientInfo} user agent detection. This can 
be overridden to choose
+* a different detection as YAUAA 
(https://github.com/nielsbasjes/yauaa) - if you do so, you
+* might exclude the maven dependency from your project in favor of a 
different framework.
 */
-   protected String getRemoteAddr(RequestCycle requestCycle)
+   public void gatherExtendedInfo()
{
-   ServletWebRequest request = 
(ServletWebRequest)requestCycle.getRequest();
-   HttpServletRequest req = request.getContainerRequest();
-   String remoteAddr = request.getHeader("X-Forwarded-For");
-
-   if (remoteAddr != null)
-   {
-   if (remoteAddr.contains(","))
-   {
-   // sometimes the header is of form client 
ip,proxy 1 ip,proxy 2 ip,...,proxy n ip,
-   // we just want the client
-   remoteAddr = Strings.split(remoteAddr, 
',')[0].trim();
-   }
-   try
-   {
-   // If ip4/6 address string handed over, simply 
does pattern validation.
-   InetAddress.getByName(remoteAddr);
-   }
-   catch (UnknownHostException e)
-   {
-   remoteAddr = req.getRemoteAddr();
-   }
-   }
-   else
+   UserAgentAnalyzer userAgentAnalyzer = 
Application.get().getMetaData(UAA_META_DATA_KEY);
+   if (userAgentAnalyzer == null)
{
-   remoteAddr = req.getRemoteAddr();
+   userAgentAnalyzer = UserAgentAnalyzer.newBuilder()
+   .hideMatcherLoadStats()
+   .withCache(25000)
+   .build();
+   Application.get().setMetaData(UAA_META_DATA_KEY, 
userAgentAnalyzer);
}
-   return remoteAddr;
+   detectBrowserProperties(userAgentAnalyzer);
}
 
/**
-* Initialize the client properties object
+* Detects browser properties like versions or the type of the browser 
and applies them to the
+* {@link ClientProperties}, override this method if there are errors 
within the browser /
+* version detection due to newer browsers
+* 
+* @param userAgentAnalyzer
+*the user agent analyzer to detect browsers and versions
 */
-   private void init()
+   protected void detectBrowserProperties(UserAgentAnalyzer 
userAgentAnalyzer)
{
-   setInternetExplorerProperties();
-   setOperaProperties();
-   setMozillaProperties();
-   setKonquerorProperties();
-   setChromeProperties();
-   setEdgeProperties();
-   setSafariProperties();
 
-   log.debug("determined user agent: {}", properties);
-   }
+   nl.basjes.parse.useragent.UserAgent parsedUserAgent = 
userAgentAnalyzer
+   .parse(getUserAgent());
+   String userAgentName = parsedUserAgent.getValue("AgentName");
 
-   /**
-* sets the konqueror specific properties
-*/
-   private void setKonquerorProperties()
-   {
-   
properties.setBrowserKonqueror(UserAgent.KONQUEROR.matches(getUserAgent()));
+   // Konqueror
+  

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445445#comment-16445445
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182968690
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/Session.java ---
@@ -422,6 +422,7 @@ public Locale getLocale()
 * @return The metadata
 * @see MetaDataKey
 */
+   @Override
public synchronized final  M getMetaData(final 
MetaDataKey key)
--- End diff --

Ah, got it.
Yeah, stupid mistake.
I think initially I mistook the error for the sync modifier, but it was the 
`T object` parameter.
Reverted that weird change.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445524#comment-16445524
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/275#discussion_r182993206
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -59,9 +58,52 @@ public void before()
}

/**
-* Test IE 6.x user-agent strings
+* Test check check all user agents
 */
@Test
+   public void testBrowsersAndVersionsOfUserAgents() {
+   // Internet Explorers
--- End diff --

Sorry for delay, here is the code works for me:

```
private static ThreadLocal localAnalyzer = new 
ThreadLocal();

@Before
public void before()
{
requestCycleMock = mock(RequestCycle.class);

webRequest = mock(ServletWebRequest.class);
when(requestCycleMock.getRequest()).thenReturn(webRequest);

servletRequest = mock(HttpServletRequest.class);

when(webRequest.getContainerRequest()).thenReturn(servletRequest);

if (localAnalyzer.get() == null) {
WebClientInfo webClientInfo = new 
WebClientInfo(requestCycleMock, "test");
webClientInfo.gatherExtendedInfo();

localAnalyzer.set(Application.get().getMetaData(WebClientInfo.UAA_META_DATA_KEY));
} else {

Application.get().setMetaData(WebClientInfo.UAA_META_DATA_KEY, 
localAnalyzer.get());
}
}

@AfterClass
public static void staticAfter()
{
localAnalyzer.set(null);
}
```

Here are the measurment results:
```
Combined tests
real0m24.123s
user1m30.748s
sys 0m1.804s


Individual tests (after above changes were applied)
real0m22.844s
user1m23.948s
sys 0m1.832s

```


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445588#comment-16445588
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on the issue:

https://github.com/apache/wicket/pull/276
  
I just realised I should probably do `IMetadataContext>`


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445579#comment-16445579
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/275
  
OK :) I'll merge my changes



> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445578#comment-16445578
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/275
  
Hi @solomax - thanks a lot for the review. Because I am not able to work on 
it currently I am going to grant you access to my repo for further commits. Is 
this ok for you?



> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445583#comment-16445583
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/275
  
I send you an invitation to the repo in which the branch of the PR is 
located. just push to it and merge if you are done. I think we are on a good 
way with this integration.


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445595#comment-16445595
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on the issue:

https://github.com/apache/wicket/pull/276
  
I went ahead and changed it.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444727#comment-16444727
 ] 

ASF GitHub Bot commented on WICKET-6550:


GitHub user Jezza opened a pull request:

https://github.com/apache/wicket/pull/276

WICKET-6550 : Unify all metadata capable objects.

Introduce a IMetadataContext that contains the current metadata
 implementation.
This should allow more generic code to be written for all of the objects
 currently capable of storing and handling metadata.
Ideally, this could be expanded with useful default methods.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Jezza/wicket WICKET-6550

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/276.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #276


commit e92bffdf596bdf96d88de3bb2fe64616a390719b
Author: Jezza 
Date:   2018-04-19T20:16:47Z

WICKET-6550 : Unify all metadata capable objects.

Introduce a IMetadataContext that contains the current metadata
 implementation.
This should allow more generic code to be written for all of the objects
 currently capable of storing and handling metadata.
Ideally, this could be expanded with useful default methods.




> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444748#comment-16444748
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182876140
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/IMetadataContext.java 
---
@@ -0,0 +1,10 @@
+package org.apache.wicket;
+
+/**
+ * @author Jezza
+ */
+public interface IMetadataContext {
--- End diff --

I don't like the names of the generics, nor the R parameter.
It was only added because the current implementation returns the object the 
method is enclosed in, so right now, it just conveys that type information.  
Ideally, I would want to remove it.

One solution would be just to return the IMetadataContext itself, but 
you wouldn't be able to do much with the return result, short of just setting 
more metadata.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16444750#comment-16444750
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user Jezza commented on a diff in the pull request:

https://github.com/apache/wicket/pull/276#discussion_r182876774
  
--- Diff: wicket-core/src/main/java/org/apache/wicket/Application.java ---
@@ -518,9 +519,13 @@ public void logResponseTarget(final IRequestHandler 
requestTarget)
 * @throws IllegalArgumentException
 * @see MetaDataKey
 */
-   public final synchronized  Application setMetaData(final 
MetaDataKey key, final Object object)
+   @Override
+   public final  Application setMetaData(final MetaDataKey key, 
final T object)
--- End diff --

I had to change the signature of this method.
Ideally, it should have been that way anyway.
Everything still compiles, which means we weren't putting values in keys 
that weren't expecting the value.

I fear that some users might be doing exactly that though, so this whole 
IMetadataContext might have to be put off for a bigger version.


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some basic 
> functionality.
> Such as a computeIfAbsent, which needs to be implemented 4 times.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16421727#comment-16421727
 ] 

ASF GitHub Bot commented on WICKET-6321:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/273#discussion_r178463264
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/markup/head/CssHeaderItem.java ---
@@ -200,7 +207,13 @@ public static CssReferenceHeaderItem 
forReference(ResourceReference reference,
public static CssReferenceHeaderItem forReference(ResourceReference 
reference,
PageParameters pageParameters, String media, String condition, 
String rel)
{
-   return new CssReferenceHeaderItem(reference, pageParameters, 
media, condition, rel);
+final CssReferenceHeaderItem cssReferenceHeaderItem = new 
CssReferenceHeaderItem(reference, pageParameters, media, condition, rel);
+if(reference instanceof IntegrityAttributed) {
--- End diff --

whitespaces: space after `if`, line break before `{`
and the whole PR


> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6533) Error while parsing xml using AjaxButton

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16421731#comment-16421731
 ] 

ASF GitHub Bot commented on WICKET-6533:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/270


> Error while parsing xml using AjaxButton
> 
>
> Key: WICKET-6533
> URL: https://issues.apache.org/jira/browse/WICKET-6533
> Project: Wicket
>  Issue Type: Bug
>Affects Versions: 8.0.0-M8
>Reporter: Łukasz Ludwa
>Priority: Major
> Attachments: showcase.zip, showcase_simplified.zip
>
>
> Problem is caused when refreshing markup using Ajax and in data is special 
> character (�).
> Error occurs in my project everywhere when refreshing markup using Ajax where 
> this special character occurs.
> I create and attach quickstart project which reproduces this problem in 
> simple way: changing markup through hiding/showing TextField by ajax button.
>  
> Steps to reproduce problem:
> 1. Download and run attached quickstart project
> 2. Enter to TextField symbol presented under "Insert this string for 
> error..." label:
> 3) Click „Regular submit” twice (this causes component to refresh, but 
> doesn’t cause error)
> 4) Now click „Ajax submit” twice – this causes button to not refresh markup 
> and show error:
>  
> {code:java}
> ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Error: Invalid 
> XML:  id="field3" >{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16421805#comment-16421805
 ] 

ASF GitHub Bot commented on WICKET-6321:


Github user klopfdreh commented on the issue:

https://github.com/apache/wicket/pull/273
  
Hi,

we are using a CORS enum for media tags already, maybe this is a good 
moment to use this class in there, too.

@svenmeier I just told that if there are more places I remember your 
suggestion  

WDYT?


> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6533) Error while parsing xml using AjaxButton

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417825#comment-16417825
 ] 

ASF GitHub Bot commented on WICKET-6533:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/270

[WICKET-6533] Unicode non-characters are skipped



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6533-non-characters

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/270.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #270


commit b85f5c0202439b404028470883f8353a44a2e034
Author: Maxim Solodovnik 
Date:   2018-03-28T17:47:08Z

[WICKET-6533] Unicode non-characters are skipped




> Error while parsing xml using AjaxButton
> 
>
> Key: WICKET-6533
> URL: https://issues.apache.org/jira/browse/WICKET-6533
> Project: Wicket
>  Issue Type: Bug
>Affects Versions: 8.0.0-M8
>Reporter: Łukasz Ludwa
>Priority: Major
> Attachments: showcase.zip, showcase_simplified.zip
>
>
> Problem is caused when refreshing markup using Ajax and in data is special 
> character (�).
> Error occurs in my project everywhere when refreshing markup using Ajax where 
> this special character occurs.
> I create and attach quickstart project which reproduces this problem in 
> simple way: changing markup through hiding/showing TextField by ajax button.
>  
> Steps to reproduce problem:
> 1. Download and run attached quickstart project
> 2. Enter to TextField symbol presented under "Insert this string for 
> error..." label:
> 3) Click „Regular submit” twice (this causes component to refresh, but 
> doesn’t cause error)
> 4) Now click „Ajax submit” twice – this causes button to not refresh markup 
> and show error:
>  
> {code:java}
> ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Error: Invalid 
> XML:  id="field3" >{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6546) CssContentHeaderItem comments CSS code with HTML comments

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424093#comment-16424093
 ] 

ASF GitHub Bot commented on WICKET-6546:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/274

[WICKET-6546] HTML comments are removed from inline CSS



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6546-no-css-comments

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/274.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #274


commit 976f28de7a890a5827ef8c160e74a40df2c87709
Author: Maxim Solodovnik 
Date:   2018-04-03T14:23:48Z

[WICKET-6546] HTML comments are removed from inline CSS




> CssContentHeaderItem comments CSS code with HTML comments
> -
>
> Key: WICKET-6546
> URL: https://issues.apache.org/jira/browse/WICKET-6546
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 6.24.0, 6.29.0
>Reporter: Robert Niestroj
>Assignee: Maxim Solodovnik
>Priority: Minor
> Attachments: wicket6546 (2).zip
>
>
> CssContentHeaderItem wraps the passed CSS in HTML comments thus rendering 
> invalid markup.
> Example code:
>  
> {code:java}
> @Override
> public void renderHead(Component component, IHeaderResponse response) {
>    super.renderHead(component, response);
>    response.render(CssContentHeaderItem.forCSS(".select2-container--open 
> {z-index: 10;}", "select2-mod", ""));
> }
> {code}
> Renders:
>  
> {code:java}
> 
> 
> {code}
> The HTML comments in the CSS make the response invalid and in the browser you 
> get a XML Parsing Error - Not Well Formed.
>  
> It should not render this invalid html comments in CSS.
> Looking at the source code i think the error is in the CssUtils class: 
> https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/core/util/string/CssUtils.java
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420686#comment-16420686
 ] 

ASF GitHub Bot commented on WICKET-6321:


GitHub user tremel opened a pull request:

https://github.com/apache/wicket/pull/273

WICKET-6321 Support Integrity and Crossorigin attributes

WICKET-6321 Support Integrity and Crossorigin attributes for 
JavaScriptUrlReferenceHeaderItem

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tremel/wicket master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/273.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #273


commit bea5c61463391099c4f06dd05607f8b9326312b8
Author: Dieter Tremel 
Date:   2018-03-30T16:40:19Z

WICKET-6321 Support Integrity and Crossorigin attributes for 
JavaScriptUrlReferenceHeaderItem




> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417692#comment-16417692
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user kbachl commented on the issue:

https://github.com/apache/wicket/pull/269
  
drop this "feature" completely - it just wont work reliable anyway


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6321) Support Integrity and Crossorigin attributes for JavaScriptUrlReferenceHeaderItem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425087#comment-16425087
 ] 

ASF GitHub Bot commented on WICKET-6321:


Github user tremel commented on the issue:

https://github.com/apache/wicket/pull/273
  
For a usage example and test I made
[CORS.zip](https://github.com/apache/wicket/files/1874596/CORS.zip), a 
mofified quickstart showing a bootstrap 4 page with bootstrap css and jquery, 
popper and bootstrap js with CORS.



> Support Integrity and Crossorigin attributes for 
> JavaScriptUrlReferenceHeaderItem 
> --
>
> Key: WICKET-6321
> URL: https://issues.apache.org/jira/browse/WICKET-6321
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Affects Versions: 8.0.0-M3
>Reporter: Mikhail Fursov
>Priority: Major
> Fix For: 8.0.0
>
> Attachments: CORS.zip, wicket-6321-20180306.diff, wicket-6321.diff
>
>
> Example of secure script reference:
>  src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.0.0-alpha.6/js/bootstrap.min.js";
>  integrity="sha256-+kIbbrvS+0dNOjhmQJzmwe/RILR/8lb/+4+PUNVW09k=" 
> crossorigin="anonymous">



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408121#comment-16408121
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/269#discussion_r176132347
  
--- Diff: 
wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
 ---
@@ -680,6 +708,35 @@ public void konqueror()
}
}
 
+   @Test
+   public void ffMobile()
+   {
+   final String userAgent = "Mozilla/5.0 (iPhone; CPU iPhone OS 
11_2_6 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 
Mobile/15D100 Safari/604.5.6";
+   WebClientInfo webClientInfo = new 
WebClientInfo(requestCycleMock, userAgent);
+
+   assertThat(userAgent, 
webClientInfo.getProperties().getBrowserVersionMajor(),
+   is(equalTo(10)));
+   assertThat(userAgent, 
webClientInfo.getProperties().getBrowserVersionMinor(),
+   is(equalTo(6)));
+   assertThat(userAgent, 
webClientInfo.getProperties().isBrowserMozillaFirefox(),
+   is(equalTo(true)));
+   assertThat(userAgent, 
webClientInfo.getProperties().isBrowserMozilla(),
--- End diff --

This part is something I don;t really like in this PR :(


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408116#comment-16408116
 ] 

ASF GitHub Bot commented on WICKET-6544:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/269

[WICKET-6544] mobile browser detection is improved



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6544-mobile-browsers

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/269.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #269


commit 0cc14749903f51057cc75d011cbc8a02a4e42f4c
Author: Maxim Solodovnik 
Date:   2018-03-21T15:44:17Z

[WICKET-6544] mobile browser detection is improved




> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409160#comment-16409160
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user martin-g commented on the issue:

https://github.com/apache/wicket/pull/269
  
With the addition of these new mobile browsers user agent strings the code 
becomes more complex.
Maybe we should think in direction how to make use of external libraries to 
do this checks, e.g. https://github.com/pieroxy/java-user-agent-detection or 
https://github.com/HaraldWalker/user-agent-utils


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6544) Chrome and Firefox on iOS detected as Safari version -1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409162#comment-16409162
 ] 

ASF GitHub Bot commented on WICKET-6544:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/269
  
And/or maybe browser list and supported patterns can be cleaned up to 
support more recent versions only?


> Chrome and Firefox on iOS detected as Safari version -1
> ---
>
> Key: WICKET-6544
> URL: https://issues.apache.org/jira/browse/WICKET-6544
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.9.0
>Reporter: Sven Ackermann
>Assignee: Maxim Solodovnik
>Priority: Major
>
> The UserAgent detection on iOS for browsers other than Safari does not work 
> correctly.
> E.g. Chrome 64 has UserAgent
> ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 
> Safari/604.1??
> which is recognized by classes {{UserAgent}} and {{WebClientInfo}} as Safari 
> with no version (-1). The problem is that the UserAgent does not contain 
> "Chrome" as required by {{UserAgent.CHROME}}, but instead "CriOS". So it is 
> recognized as Safari, but since it does not contain "version/", no version is 
> set.
> A similar problem exists for Firefox on iOS where the UserAgent contains 
> "FxiOS" instead of "Firefox":
>  ??Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) 
> AppleWebKit/604.5.6 (KHTML, like Gecko) FxiOS/10.6b8836 Mobile/15D100 
> Safari/604.5.6??
> In our application this causes some unwanted redirects to legacy pages 
> because we think it is an old Safari browser with no support for some 
> features our pages need. But of course the Chrome und Firefox versions above 
> support all that.
> see also 
> [https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent|https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent,]
>  and 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox#Firefox_for_iOS]
>  
> Thanks for looking into it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6528) Component part of Page check in AjaxRequestHandler breaks applications

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386218#comment-16386218
 ] 

ASF GitHub Bot commented on WICKET-6528:


Github user dashorst closed the pull request at:

https://github.com/apache/wicket/pull/265


> Component part of Page check in AjaxRequestHandler breaks applications
> --
>
> Key: WICKET-6528
> URL: https://issues.apache.org/jira/browse/WICKET-6528
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 8.0.0-M8
>Reporter: Martijn Dashorst
>Priority: Blocker
> Fix For: 8.0.0
>
>
> The check if a component is part of the page hierarchy where an Ajax response 
> is generated for breaks client applications in a most unpleasant way. While 
> this check is good™, it should only generate errors in development mode. In 
> deployment mode it should ignore the component (like in versions prior to 
> Wicket 8) and log it as an error (which is expected: the application is in 
> error).
> See method `public void add(Component... components)` in AjaxRequestHandler 
> for more details.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6528) Component part of Page check in AjaxRequestHandler breaks applications

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386219#comment-16386219
 ] 

ASF GitHub Bot commented on WICKET-6528:


Github user dashorst commented on the issue:

https://github.com/apache/wicket/pull/265
  
Is merged with commit 
https://github.com/apache/wicket/commit/3be55cf5a24982cfca400225aabb6c4296859a7d


> Component part of Page check in AjaxRequestHandler breaks applications
> --
>
> Key: WICKET-6528
> URL: https://issues.apache.org/jira/browse/WICKET-6528
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 8.0.0-M8
>Reporter: Martijn Dashorst
>Priority: Blocker
> Fix For: 8.0.0
>
>
> The check if a component is part of the page hierarchy where an Ajax response 
> is generated for breaks client applications in a most unpleasant way. While 
> this check is good™, it should only generate errors in development mode. In 
> deployment mode it should ignore the component (like in versions prior to 
> Wicket 8) and log it as an error (which is expected: the application is in 
> error).
> See method `public void add(Component... components)` in AjaxRequestHandler 
> for more details.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646862#comment-16646862
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/294
  
Ha, that's really some crufty code :)

Just noticed that you filed the issue for Wicket 6.x - note that we will 
only apply security fixes for that version.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646990#comment-16646990
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
@svenmeier it still exists in 7, 8 and in 9 snapshot. Are there jiras for 
appropriate versions? Didn't find them.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648443#comment-16648443
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
Shoud I create a new PR without a ticket name or rewording commit is enough?


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Minor
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648519#comment-16648519
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/294
  
I'm still not happy about the change :/.

Note that for Wicket 9 I want to move all Drag-handling from wicket-ajax to 
modal.js - we don't need it really in the former and for modal we'll have it 
easier to adjust it.

For now we could allow the start handler to veto the drag:

```
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js 
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
index 18ab6bd..e71b4e8 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
+++ 
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
@@ -2476,14 +2476,16 @@
 
var element = this;
 
+   if (element.wicketOnDragBegin(element, e) === 
false) {
+   return;
+   }
+
Wicket.Event.stop(e);
 
if (e.preventDefault) {
e.preventDefault();
}
 
-   element.wicketOnDragBegin(element);
-
element.lastMouseX = e.clientX;
element.lastMouseY = e.clientY;
 
diff --git 
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
 
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
index b00ceec..6d63807 100644
--- 
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
+++ 
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
@@ -901,7 +901,12 @@
/**
 * Called when dragging has started.
 */
-   onBegin: function(object) {
+   onBegin: function(element, event) {
+   // ignore anything inside the content
+   if (jQuery(event.target).closest('.w_content_2').size() 
) {
+   return false;
+   }
+   
if (this.isIframe() && (Wicket.Browser.isGecko() || 
Wicket.Browser.isIELessThan11() || Wicket.Browser.isSafari())) {
this.revertList = [];
Wicket.Iframe.documentFix(document, 
this.revertList);
@@ -1183,7 +1188,7 @@
""+
""+
""+
-   ""+
+   ""+
""+

""+

""+

```


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Minor
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been 

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648566#comment-16648566
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
@svenmeier Do you plan to completely remove the drag handling from 
wicket-ajax or just to allow the modal.js control it by itself?


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Minor
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650856#comment-16650856
 ] 

ASF GitHub Bot commented on WICKET-6427:


Github user Jezza commented on the issue:

https://github.com/apache/wicket/pull/223
  
I'm moving my branches around, so I guess github spotted that it's no 
longer on my master branch.

I, personally, don't have any need of this ticket anymore, and honestly, 
there's a lot of work to do.
I think I got, maybe, 25% of the way through the tests.
I did have to change all of them, so I think unless someone wants it, I'll 
just let it lie.


> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered, 
> and it seemed weird to only have the event fired for one set of ajax related 
> calls.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6427) Fire an event once all ajax timers are registered

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650853#comment-16650853
 ] 

ASF GitHub Bot commented on WICKET-6427:


Github user Jezza closed the pull request at:

https://github.com/apache/wicket/pull/223


> Fire an event once all ajax timers are registered
> -
>
> Key: WICKET-6427
> URL: https://issues.apache.org/jira/browse/WICKET-6427
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Jezza
>Priority: Minor
>
> This is in the same vein as WICKET-5746.
> I just need some way to execute code after the timers have been registered, 
> and it seemed weird to only have the event fired for one set of ajax related 
> calls.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650852#comment-16650852
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/294
  
I've fixed WICKET-5552, please open a new pull request if you think 
ModalWindow is in need of further extensibility.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Assignee: Sven Meier
>Priority: Minor
>  Labels: javascript, modalwindow
> Fix For: 8.2.0
>
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650956#comment-16650956
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon closed the pull request at:

https://github.com/apache/wicket/pull/294


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Assignee: Sven Meier
>Priority: Minor
>  Labels: javascript, modalwindow
> Fix For: 8.2.0
>
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6586) Broken JavaScript due to fix charsetName in JavaScriptPackageResource

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649952#comment-16649952
 ] 

ASF GitHub Bot commented on WICKET-6586:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/295
  
+1


> Broken JavaScript due to fix charsetName in JavaScriptPackageResource
> -
>
> Key: WICKET-6586
> URL: https://issues.apache.org/jira/browse/WICKET-6586
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.10.0
>Reporter: Andreas Müller
>Assignee: Martin Grigorov
>Priority: Major
>
> When running Wicket in DEPLOYMENT Mode, {{DefaultJavaScriptCompressor}} will 
> be set as JavaScript Compressor by default to strip Comments and Whitespaces 
> from JavaScript files.
> In {{JavaScriptPackageResource}} the {{processResponse}} method sets the 
> charsetName fix to "UTF-8", when compressing JS files:
> {code:java}
> @Override
> protected byte[] processResponse(final Attributes attributes, byte[] bytes)
> {
>  final byte[] processedResponse = super.processResponse(attributes, bytes);
>  IJavaScriptCompressor compressor = getCompressor();
>  if (compressor != null && getCompress())
>  {
>   try
>   {
>String charsetName = "UTF-8";
> ...{code}
> If those JavaScript files are not in UTF-8, the Compressor can break those 
> files.
> E.g. when using ISO-8859-15 and having umlauts in the file, the umlauts will 
> be replaced by the REPLACEMENT CHARACTER "\uefbfbd".
> There should be a way to specify the charsetName in 
> {{JavaScriptPackageResource}}.
> E.g. by calling something like 
> {{getResourceSettings().setJavaScriptCharset()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6435) WicketTester should provide assertExists and assertNotExists methods

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16652511#comment-16652511
 ] 

ASF GitHub Bot commented on WICKET-6435:


GitHub user Jezza opened a pull request:

https://github.com/apache/wicket/pull/298

WICKET-6435: Add assertAbsent to BaseWicketTester.

Closes WICKET-6435

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Jezza/wicket WICKET-6435

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/298.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #298


commit 57e01144e07d2c6135f375fc54c46319c45d0431
Author: Jezza 
Date:   2018-10-16T21:56:22Z

WICKET-6435: Add assertAbsent to BaseWicketTester.




> WicketTester should provide assertExists and assertNotExists methods
> 
>
> Key: WICKET-6435
> URL: https://issues.apache.org/jira/browse/WICKET-6435
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Kamil
>Priority: Major
>
> BaseWicketTester has:
> {code}
> private Component assertExists(final String path)
> {code}
> which is unfortunately private and doesn't provide contrary method.
> These methods are very important if you want to properly test code which is 
> using Fragments: one Fragment is being added at time (exist) while another is 
> not added (notExist)
> Could you please make assertExists public and add assertNotExists method?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6586) Broken JavaScript due to fix charsetName in JavaScriptPackageResource

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647552#comment-16647552
 ] 

ASF GitHub Bot commented on WICKET-6586:


GitHub user martin-g opened a pull request:

https://github.com/apache/wicket/pull/295

WICKET-6586 Broken JavaScript due to fix charsetName in JavaScriptPac…

…kageResource

Introduce PackageResource#getProcessingEncoding() that could be overridden 
by the application to use a custom encoding to read a resource from the class 
path.
Move the compressing logic from Css/JavaScript-PackageResource to 
PackageResource class to DRY it.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket 
WICKET-6586-introduce-processing-encoding

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/295.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #295


commit 072b2fc7fd521ec07e40fc5af16b75db47694b33
Author: Martin Tzvetanov Grigorov 
Date:   2018-10-12T06:58:04Z

WICKET-6586 Broken JavaScript due to fix charsetName in 
JavaScriptPackageResource

Introduce PackageResource#getProcessingEncoding() that could be overridden 
by the application to use a custom encoding to read a resource from the class 
path.
Move the compressing logic from Css/JavaScript-PackageResource to 
PackageResource class to DRY it.




> Broken JavaScript due to fix charsetName in JavaScriptPackageResource
> -
>
> Key: WICKET-6586
> URL: https://issues.apache.org/jira/browse/WICKET-6586
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.10.0
>Reporter: Andreas Müller
>Assignee: Martin Grigorov
>Priority: Major
>
> When running Wicket in DEPLOYMENT Mode, {{DefaultJavaScriptCompressor}} will 
> be set as JavaScript Compressor by default to strip Comments and Whitespaces 
> from JavaScript files.
> In {{JavaScriptPackageResource}} the {{processResponse}} method sets the 
> charsetName fix to "UTF-8", when compressing JS files:
> {code:java}
> @Override
> protected byte[] processResponse(final Attributes attributes, byte[] bytes)
> {
>  final byte[] processedResponse = super.processResponse(attributes, bytes);
>  IJavaScriptCompressor compressor = getCompressor();
>  if (compressor != null && getCompress())
>  {
>   try
>   {
>String charsetName = "UTF-8";
> ...{code}
> If those JavaScript files are not in UTF-8, the Compressor can break those 
> files.
> E.g. when using ISO-8859-15 and having umlauts in the file, the umlauts will 
> be replaced by the REPLACEMENT CHARACTER "\uefbfbd".
> There should be a way to specify the charsetName in 
> {{JavaScriptPackageResource}}.
> E.g. by calling something like 
> {{getResourceSettings().setJavaScriptCharset()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649055#comment-16649055
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/294
  
It is used by ModalWindow and the Ajax debug console only - if we can agree 
to remove the latter (has been discussed a few years already), we can just move 
the code to modal.js
But that's a separate discussion.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 7.10.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Minor
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6586) Broken JavaScript due to fix charsetName in JavaScriptPackageResource

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651250#comment-16651250
 ] 

ASF GitHub Bot commented on WICKET-6586:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/295


> Broken JavaScript due to fix charsetName in JavaScriptPackageResource
> -
>
> Key: WICKET-6586
> URL: https://issues.apache.org/jira/browse/WICKET-6586
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 7.10.0
>Reporter: Andreas Müller
>Assignee: Martin Grigorov
>Priority: Major
>
> When running Wicket in DEPLOYMENT Mode, {{DefaultJavaScriptCompressor}} will 
> be set as JavaScript Compressor by default to strip Comments and Whitespaces 
> from JavaScript files.
> In {{JavaScriptPackageResource}} the {{processResponse}} method sets the 
> charsetName fix to "UTF-8", when compressing JS files:
> {code:java}
> @Override
> protected byte[] processResponse(final Attributes attributes, byte[] bytes)
> {
>  final byte[] processedResponse = super.processResponse(attributes, bytes);
>  IJavaScriptCompressor compressor = getCompressor();
>  if (compressor != null && getCompress())
>  {
>   try
>   {
>String charsetName = "UTF-8";
> ...{code}
> If those JavaScript files are not in UTF-8, the Compressor can break those 
> files.
> E.g. when using ISO-8859-15 and having umlauts in the file, the umlauts will 
> be replaced by the REPLACEMENT CHARACTER "\uefbfbd".
> There should be a way to specify the charsetName in 
> {{JavaScriptPackageResource}}.
> E.g. by calling something like 
> {{getResourceSettings().setJavaScriptCharset()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6603) WicketTester.destroy sometimes hangs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665333#comment-16665333
 ] 

ASF GitHub Bot commented on WICKET-6603:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/300


> WicketTester.destroy sometimes hangs
> 
>
> Key: WICKET-6603
> URL: https://issues.apache.org/jira/browse/WICKET-6603
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.1.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Critical
> Fix For: 8.2.0, 9.0.0
>
>
> Hi all,
> I'm experiencing some jetty-shutdown problems after upgrading from 7.9 to
>  8.1. See the stacktrace below.
> Is there a simple remedy for this? (or a known cause?) It is annoying
>  because this error prevents Jetty from shutting down, and I use this in my
>  tests, so my tests never end... :(
> Btw. I'm on java 10.0.2 and jetty version 9.2.5.v20141112
> {code:java}
> 2018-10-12 11:24:25,738 ERROR - AsynchronousDataStore  -
> java.lang.InterruptedException
> at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1259)
> at 
> java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:373)
> at
> org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:207)
> at
> org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
> at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
> at
> org.apache.wicket.pageStore.AsynchronousPageStore$PageSavingRunnable.run(AsynchronousPageStore.java:225)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6603) WicketTester.destroy sometimes hangs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663834#comment-16663834
 ] 

ASF GitHub Bot commented on WICKET-6603:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/300
  
nice catch :)
I'll update PR, thanks!


> WicketTester.destroy sometimes hangs
> 
>
> Key: WICKET-6603
> URL: https://issues.apache.org/jira/browse/WICKET-6603
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.1.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Critical
> Fix For: 8.2.0, 9.0.0
>
>
> Hi all,
> I'm experiencing some jetty-shutdown problems after upgrading from 7.9 to
>  8.1. See the stacktrace below.
> Is there a simple remedy for this? (or a known cause?) It is annoying
>  because this error prevents Jetty from shutting down, and I use this in my
>  tests, so my tests never end... :(
> Btw. I'm on java 10.0.2 and jetty version 9.2.5.v20141112
> {code:java}
> 2018-10-12 11:24:25,738 ERROR - AsynchronousDataStore  -
> java.lang.InterruptedException
> at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1259)
> at 
> java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:373)
> at
> org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:207)
> at
> org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
> at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
> at
> org.apache.wicket.pageStore.AsynchronousPageStore$PageSavingRunnable.run(AsynchronousPageStore.java:225)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6603) WicketTester.destroy sometimes hangs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663836#comment-16663836
 ] 

ASF GitHub Bot commented on WICKET-6603:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/300
  
It would be impossible to call `pageSavingThread.join();` to ensure Thread 
is stopped
Would it be OK?


> WicketTester.destroy sometimes hangs
> 
>
> Key: WICKET-6603
> URL: https://issues.apache.org/jira/browse/WICKET-6603
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.1.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Critical
> Fix For: 8.2.0, 9.0.0
>
>
> Hi all,
> I'm experiencing some jetty-shutdown problems after upgrading from 7.9 to
>  8.1. See the stacktrace below.
> Is there a simple remedy for this? (or a known cause?) It is annoying
>  because this error prevents Jetty from shutting down, and I use this in my
>  tests, so my tests never end... :(
> Btw. I'm on java 10.0.2 and jetty version 9.2.5.v20141112
> {code:java}
> 2018-10-12 11:24:25,738 ERROR - AsynchronousDataStore  -
> java.lang.InterruptedException
> at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1259)
> at 
> java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:373)
> at
> org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:207)
> at
> org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
> at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
> at
> org.apache.wicket.pageStore.AsynchronousPageStore$PageSavingRunnable.run(AsynchronousPageStore.java:225)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6603) WicketTester.destroy sometimes hangs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663971#comment-16663971
 ] 

ASF GitHub Bot commented on WICKET-6603:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/300
  
I like to minimize the count of member variables:

```
@Override
public void destroy()
{
final Thread pageSavingThread = this.pageSavingThread;
this.pageSavingThread = null;
if (pageSavingThread.isAlive())
{
try
{
pageSavingThread.join();

@Override
public void storePage(String sessionId, IManageablePage page)
{
if (pageSavingThread == null)
{
return;
}
```

Your boolean works fine too.


> WicketTester.destroy sometimes hangs
> 
>
> Key: WICKET-6603
> URL: https://issues.apache.org/jira/browse/WICKET-6603
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.1.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Critical
> Fix For: 8.2.0, 9.0.0
>
>
> Hi all,
> I'm experiencing some jetty-shutdown problems after upgrading from 7.9 to
>  8.1. See the stacktrace below.
> Is there a simple remedy for this? (or a known cause?) It is annoying
>  because this error prevents Jetty from shutting down, and I use this in my
>  tests, so my tests never end... :(
> Btw. I'm on java 10.0.2 and jetty version 9.2.5.v20141112
> {code:java}
> 2018-10-12 11:24:25,738 ERROR - AsynchronousDataStore  -
> java.lang.InterruptedException
> at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1259)
> at 
> java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:373)
> at
> org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:207)
> at
> org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
> at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
> at
> org.apache.wicket.pageStore.AsynchronousPageStore$PageSavingRunnable.run(AsynchronousPageStore.java:225)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6603) WicketTester.destroy sometimes hangs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661886#comment-16661886
 ] 

ASF GitHub Bot commented on WICKET-6603:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/300

[WICKET-6603] Asypc page/data store destroyed without hanging



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6603-wickettester-hang

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/300.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #300


commit 1a558850ff4cd4bb56c4f32a613f116dde7ea617
Author: Maxim Solodovnik 
Date:   2018-10-24T07:51:26Z

[WICKET-6603] Asypc page/data store destroyed without hanging




> WicketTester.destroy sometimes hangs
> 
>
> Key: WICKET-6603
> URL: https://issues.apache.org/jira/browse/WICKET-6603
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.1.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Critical
> Fix For: 8.2.0, 9.0.0
>
>
> Hi all,
> I'm experiencing some jetty-shutdown problems after upgrading from 7.9 to
>  8.1. See the stacktrace below.
> Is there a simple remedy for this? (or a known cause?) It is annoying
>  because this error prevents Jetty from shutting down, and I use this in my
>  tests, so my tests never end... :(
> Btw. I'm on java 10.0.2 and jetty version 9.2.5.v20141112
> {code:java}
> 2018-10-12 11:24:25,738 ERROR - AsynchronousDataStore  -
> java.lang.InterruptedException
> at 
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1259)
> at 
> java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:317)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:373)
> at
> org.apache.wicket.pageStore.AsynchronousDataStore.storeData(AsynchronousDataStore.java:207)
> at
> org.apache.wicket.pageStore.AbstractPageStore.storePageData(AbstractPageStore.java:119)
> at
> org.apache.wicket.pageStore.DefaultPageStore.storePage(DefaultPageStore.java:66)
> at
> org.apache.wicket.pageStore.AsynchronousPageStore$PageSavingRunnable.run(AsynchronousPageStore.java:225)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6435) WicketTester should provide assertExists and assertNotExists methods

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678137#comment-16678137
 ] 

ASF GitHub Bot commented on WICKET-6435:


Github user Jezza commented on the issue:

https://github.com/apache/wicket/pull/298
  
Glad I could help.


> WicketTester should provide assertExists and assertNotExists methods
> 
>
> Key: WICKET-6435
> URL: https://issues.apache.org/jira/browse/WICKET-6435
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Kamil
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.2.0, 9.0.0
>
>
> BaseWicketTester has:
> {code}
> private Component assertExists(final String path)
> {code}
> which is unfortunately private and doesn't provide contrary method.
> These methods are very important if you want to properly test code which is 
> using Fragments: one Fragment is being added at time (exist) while another is 
> not added (notExist)
> Could you please make assertExists public and add assertNotExists method?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6435) WicketTester should provide assertExists and assertNotExists methods

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678136#comment-16678136
 ] 

ASF GitHub Bot commented on WICKET-6435:


Github user Jezza closed the pull request at:

https://github.com/apache/wicket/pull/298


> WicketTester should provide assertExists and assertNotExists methods
> 
>
> Key: WICKET-6435
> URL: https://issues.apache.org/jira/browse/WICKET-6435
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Kamil
>Assignee: Martin Grigorov
>Priority: Major
> Fix For: 8.2.0, 9.0.0
>
>
> BaseWicketTester has:
> {code}
> private Component assertExists(final String path)
> {code}
> which is unfortunately private and doesn't provide contrary method.
> These methods are very important if you want to properly test code which is 
> using Fragments: one Fragment is being added at time (exist) while another is 
> not added (notExist)
> Could you please make assertExists public and add assertNotExists method?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6435) WicketTester should provide assertExists and assertNotExists methods

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677833#comment-16677833
 ] 

ASF GitHub Bot commented on WICKET-6435:


Github user martin-g commented on the issue:

https://github.com/apache/wicket/pull/298
  
I've merged the PR but due to merge conflict GitHub doesn't recognize the 
commit automatically to close the PR.
@Jezza Please close the PR because we cannot do it ourselves.
Thank you for your help!


> WicketTester should provide assertExists and assertNotExists methods
> 
>
> Key: WICKET-6435
> URL: https://issues.apache.org/jira/browse/WICKET-6435
> Project: Wicket
>  Issue Type: Improvement
>Reporter: Kamil
>Priority: Major
>
> BaseWicketTester has:
> {code}
> private Component assertExists(final String path)
> {code}
> which is unfortunately private and doesn't provide contrary method.
> These methods are very important if you want to properly test code which is 
> using Fragments: one Fragment is being added at time (exist) while another is 
> not added (notExist)
> Could you please make assertExists public and add assertNotExists method?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642682#comment-16642682
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
Is there anything else I should rework here?


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645346#comment-16645346
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/294
  
Why so complicated - I've fixed the issue by removing the mouse blocker 
from modal.js and restricting any dragging on the element itself:

```
diff --git 
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js 
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
index 64852de..8d94b36 100644
--- 
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
+++ 
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
@@ -2485,6 +2485,10 @@
 
mouseDownHandler: function (e) {
e = Wicket.Event.fix(e);
+   
+   if (e.target !== this) {
+   return;
+   }
 
var element = this;
 
diff --git 
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
 
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
index f683119..5a0f122 100644
--- 
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
+++ 
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
@@ -1189,7 +1189,7 @@
""+
""+
""+
-   ""+
+   ""+
""+

""+

""+
```
Can you try that instead?


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645740#comment-16645740
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
@svenmeier sure, it was the first thing I tried. Unfortunately it prevents 
the w_captionText of the popup from working as a drag area, which I think is 
undesired effect.

Potentially can be done as something like `e.target !== this && 
e.target.className.indexOf('w_captionText') == -1`, but it makes the 
mouseDownHandler know about css classes of modal so I think the approach with 
some general stopper class is more universal.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6587) CheckBoxSelector should accept more CheckBoxes to be added later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623413#comment-16623413
 ] 

ASF GitHub Bot commented on WICKET-6587:


Github user duesenklipper commented on the issue:

https://github.com/apache/wicket/pull/292
  
That is a possibility, yes, though in your example you do hold on to the 
connectedCheckBoxes. My main idea was to keep it simple, by providing 
addCheckBox() users can just add checkboxes in a loop, e.g. in 
ListView#populateItem.

Any checkboxes that are removed from the component hierarchy are cleared 
from connectedCheckBoxes by the attached behavior, so there shouldn't be a leak.

But I'm not heavily invested in this design, if you prefer a lookup method, 
I can do that.


> CheckBoxSelector should accept more CheckBoxes to be added later
> 
>
> Key: WICKET-6587
> URL: https://issues.apache.org/jira/browse/WICKET-6587
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Affects Versions: 8.0.0, 7.10.0
>Reporter: Carl-Eric Menzel
>Assignee: Carl-Eric Menzel
>Priority: Major
>
> CheckBoxSelector currently only allows attaching CheckBoxes at construction 
> time. Sometimes additional CheckBoxes may need to be added later.
> I'm preparing a patch for this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6587) CheckBoxSelector should accept more CheckBoxes to be added later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624182#comment-16624182
 ] 

ASF GitHub Bot commented on WICKET-6587:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/292
  
Ah, I didn't notice your cleanup behavior. That's an improvement to the old 
solution already +1.

I just think that a dynamic lookup with an overriden #getCheckBoxes() would 
be more flexible. Why not do both: Add the cleanup all checkboxes passed in the 
constructor *and* let users override the lookup method if they want/need to.


> CheckBoxSelector should accept more CheckBoxes to be added later
> 
>
> Key: WICKET-6587
> URL: https://issues.apache.org/jira/browse/WICKET-6587
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-core
>Affects Versions: 8.0.0, 7.10.0
>Reporter: Carl-Eric Menzel
>Assignee: Carl-Eric Menzel
>Priority: Major
>
> CheckBoxSelector currently only allows attaching CheckBoxes at construction 
> time. Sometimes additional CheckBoxes may need to be added later.
> I'm preparing a patch for this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6550) Unify all metadata capable objects.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628430#comment-16628430
 ] 

ASF GitHub Bot commented on WICKET-6550:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/276


> Unify all metadata capable objects.
> ---
>
> Key: WICKET-6550
> URL: https://issues.apache.org/jira/browse/WICKET-6550
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket
>Reporter: Jezza
>Priority: Minor
> Fix For: 9.0.0
>
> Attachments: Test.java, mock.txt
>
>
> Application, Session, RequestCycle, and Component all have #setMetadata and 
> #getMetadata methods, but lack some super object to unify them all.
> These leads to annoying complex code if you wish to implement some extra 
> functionality.
> I propose that we unify them all with one interface.
> I've attached a mock idea that would solve it, and I'll work on a prototype 
> and submit a PR so anyone can take a look.
> I'll add a comment here with the PR number.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628259#comment-16628259
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user solomax commented on a diff in the pull request:

https://github.com/apache/wicket/pull/294#discussion_r220426844
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js 
---
@@ -2301,6 +2302,10 @@
onDrag = jQuery.noop;
}
 
+   if (typeof(settings) !== "undefined" && 
settings.stopDragOnCssSelector) {
--- End diff --

According to the code `settings` should be `object`
Maybe it would be better to change this line to be
`typeof(settings) === 'object'` ?


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628260#comment-16628260
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on a diff in the pull request:

https://github.com/apache/wicket/pull/294#discussion_r220427102
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js 
---
@@ -2301,6 +2302,10 @@
onDrag = jQuery.noop;
}
 
+   if (typeof(settings) !== "undefined" && 
settings.stopDragOnCssSelector) {
--- End diff --

True. I'll change it to === 'object'. Will check that it still works and 
push.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628211#comment-16628211
 ] 

ASF GitHub Bot commented on WICKET-5552:


GitHub user andruhon opened a pull request:

https://github.com/apache/wicket/pull/294

WICKET-5552 fix modal mousedown and make modal more extendable

Demo to reproduce the issue 
https://github.com/andruhon/wicket-modal-mousedown-issue

Demo using 9.0.0-SNAPSHOT from maven local to demonstrate the fix:

https://github.com/andruhon/wicket-modal-mousedown-issue/tree/fix-WICKET-5552

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/andruhon/wicket 
WICKET-5552-fix-modal-mousedown-and-make-it-more-extendable

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/294.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #294


commit 3adf1b5144b5948c45100129c6279fa183d85420
Author: Andrew Kondratev 
Date:   2018-09-26T02:58:11Z

WICKET-5552 fix modal mousedown and make it more extendable




> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628304#comment-16628304
 ] 

ASF GitHub Bot commented on WICKET-5552:


Github user andruhon commented on the issue:

https://github.com/apache/wicket/pull/294
  
Updated with typeof object check.


> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
>  Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time 
> picker, when clicking outside of the pop-up window but over the modal window, 
> mousedown/click events are not propagated. Clicks outside of the modal window 
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the 
> w_content_1 component. Removal of this leads to the Drag javascript being 
> executed which itself calls Wicket.Event.stop(event), disabling this then 
> propagates the event which leads to the pop-up window being closed but causes 
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a 
> page. You will see that launching the modal window and clicking on the time 
> component opens the pop-up window. However, you can only get this to close 
> when clicking outside of the modal window. The same component has been put on 
> the main page as a comparison which does close when clicking outside of the 
> pop-up window.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706134#comment-16706134
 ] 

ASF GitHub Bot commented on WICKET-6617:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/343

[WICKET-6617] headers are added to header-items if specified



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6617-header-placeholder

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/343.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #343


commit a529aadafdaf7b32e909bbf90fe32822e841877f
Author: Maxim Solodovnik 
Date:   2018-12-02T08:09:37Z

[WICKET-6617] headers are added to header-items if specified




> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
>
> Components added via AJAX and contributing to  using @Override 
> renderHead ignores  if any



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6608) Stateless page, mix of queue and add can cause unforseen consequences

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16705993#comment-16705993
 ] 

ASF GitHub Bot commented on WICKET-6608:


GitHub user svenmeier opened a pull request:

https://github.com/apache/wicket/pull/342

Wicket 6616 always render new pages

Question: Should Wicket always render new pages before any component in it 
is accessed?

  * until 8.1.0
* components can be accessed **un-rendered** when already inside the 
page hierarchy
* then the page is prepared for render
* any component added in onInitialize() or onBeforeRender() can be 
accessed **rendered**
  * since 8.2.0 (WICKET-6608)
* components can be accessed **un-rendered** when already inside the 
page hierarchy
* then the page is initialized
* any component added in onInitialize()  (e.g. through queueing) can be 
accessed **rendered**
* then the page is prepared for render
* any component added in onBeforeRender() can be accessed **rendered**

IMHO all these cases should allow access to **rendered** component only.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6616-render-new-pages

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/342.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #342


commit 7b2bb1162dd80e6faab9fb9f0fc30c0d153a4bd2
Author: Sven Meier 
Date:   2018-11-30T15:10:18Z

Revert "WICKET-6608 Stateless page, mix of queue and add can cause 
unforseen"

This reverts commit 61c8709389cea30975814530f53dd0ae1f1ea592.

commit a446138852fe1748ff879d85bced1b19f8af444e
Author: Sven Meier 
Date:   2018-11-30T15:10:21Z

Revert "WICKET-6608 added test case"

This reverts commit 86f92fc8cfaf4ec15409908455d049f9466c542e.

commit 557115433e3485fc6ab50607ae930ff46c14c80a
Author: Sven Meier 
Date:   2018-12-01T20:14:40Z

WICKET-6616 always render new pages




> Stateless page, mix of queue and add can cause unforseen consequences
> -
>
> Key: WICKET-6608
> URL: https://issues.apache.org/jira/browse/WICKET-6608
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket
>Affects Versions: 8.1.0
>Reporter: Oddgeir Bell
>Assignee: Andrea Del Bene
>Priority: Minor
> Fix For: 8.2.0, 9.0.0
>
> Attachments: statelessQueueAdd.zip
>
>
> We are in the process of upgrading a Wicket 6.x application to Wicket 8.1, 
> mostly because we needed stateless ajax.
> In the process we discovered something quite unexpected (took a few days to 
> figure out the cause).
> This is the issue:
> Stateless page.
> Hierarchy like so:
> Page
>      ->Container
>             ->Label
>             ->AjaxButton
>  
> The label should only be visible when it's model has data, so we override 
> onConfigure and set visible = (getDefaultModelObject != null).
> This works if all components are added with add(Component).
> It also works if all components are added with queue(Component).
> BUT, if the container is added with add(Component) and the AjaxButton is 
> added with queue(Component), it doesn't work.
> Actually, if just one component is added to the page with queue(Component), 
> things seem to work (as long as it is queue-ed AFTER the container is add-ed)
> I could not find any information on dangers of mixing add/queue with my 
> google-fu, so it may look like it's a bug?
>  
> Attached quickstart that shows the issue.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713571#comment-16713571
 ] 

ASF GitHub Bot commented on WICKET-6617:


Github user svenmeier commented on the issue:

https://github.com/apache/wicket/pull/343
  
We should leave 7.x for people with support for  older browsers. Let them 
migrate to 8.x if they need newer features.


> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 8.3.0, 9.0.0
>
>
> Components added via AJAX and contributing to {{}} using {{@Override 
> renderHead}} ignores {{}} if any
> Here is the example:
> Imaging you have following markup:
> {code}
> 
>   
> 
> Hello
>   
>   
>   
>   
> 
> {code}
> In your java code you replacing component A with component B on the page via 
> AJAX
> Component B contributing to {{}} as follows:
> {code}
>   @Override
>   public void renderHead(IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(JavaScriptHeaderItem.forReference(new 
> JavaScriptResourceReference(B.class, "some.js")));
>   }
> {code}
> As developer I would expect additional JS/CSS files (or any other header 
> resources) will be appended before {{}} tag since I have placed 
> {{}} tag
> Currently only initial header resources will take {{}} 
> into account



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713583#comment-16713583
 ] 

ASF GitHub Bot commented on WICKET-6617:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/343
  
OK :)


> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 8.3.0, 9.0.0
>
>
> Components added via AJAX and contributing to {{}} using {{@Override 
> renderHead}} ignores {{}} if any
> Here is the example:
> Imaging you have following markup:
> {code}
> 
>   
> 
> Hello
>   
>   
>   
>   
> 
> {code}
> In your java code you replacing component A with component B on the page via 
> AJAX
> Component B contributing to {{}} as follows:
> {code}
>   @Override
>   public void renderHead(IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(JavaScriptHeaderItem.forReference(new 
> JavaScriptResourceReference(B.class, "some.js")));
>   }
> {code}
> As developer I would expect additional JS/CSS files (or any other header 
> resources) will be appended before {{}} tag since I have placed 
> {{}} tag
> Currently only initial header resources will take {{}} 
> into account



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6620) @Deprecated classes/methods need to be removed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713546#comment-16713546
 ] 

ASF GitHub Bot commented on WICKET-6620:


Github user asfgit closed the pull request at:

https://github.com/apache/wicket/pull/344


> @Deprecated classes/methods need to be removed
> --
>
> Key: WICKET-6620
> URL: https://issues.apache.org/jira/browse/WICKET-6620
> Project: Wicket
>  Issue Type: Task
>  Components: wicket
>Affects Versions: 9.0.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 9.0.0
>
>
> @Deprecated classes/methods need to be removed
> 1) Drop all `@Deprecated(since = "8.0", forRemoval = true)` from master
> 2) Drop all marked as @Deprecated in wicket7 from master



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713524#comment-16713524
 ] 

ASF GitHub Bot commented on WICKET-6617:


Github user solomax commented on the issue:

https://github.com/apache/wicket/pull/343
  
@svenmeier  Should this be merged into 7.x?


> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
>
> Components added via AJAX and contributing to {{}} using {{@Override 
> renderHead}} ignores {{}} if any
> Here is the example:
> Imaging you have following markup:
> {code}
> 
>   
> 
> Hello
>   
>   
>   
>   
> 
> {code}
> In your java code you replacing component A with component B on the page via 
> AJAX
> Component B contributing to {{}} as follows:
> {code}
>   @Override
>   public void renderHead(IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(JavaScriptHeaderItem.forReference(new 
> JavaScriptResourceReference(B.class, "some.js")));
>   }
> {code}
> As developer I would expect additional JS/CSS files (or any other header 
> resources) will be appended before {{}} tag since I have placed 
> {{}} tag
> Currently only initial header resources will take {{}} 
> into account



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713542#comment-16713542
 ] 

ASF GitHub Bot commented on WICKET-6617:


Github user solomax closed the pull request at:

https://github.com/apache/wicket/pull/343


> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
>
> Components added via AJAX and contributing to {{}} using {{@Override 
> renderHead}} ignores {{}} if any
> Here is the example:
> Imaging you have following markup:
> {code}
> 
>   
> 
> Hello
>   
>   
>   
>   
> 
> {code}
> In your java code you replacing component A with component B on the page via 
> AJAX
> Component B contributing to {{}} as follows:
> {code}
>   @Override
>   public void renderHead(IHeaderResponse response) {
>   super.renderHead(response);
>   response.render(JavaScriptHeaderItem.forReference(new 
> JavaScriptResourceReference(B.class, "some.js")));
>   }
> {code}
> As developer I would expect additional JS/CSS files (or any other header 
> resources) will be appended before {{}} tag since I have placed 
> {{}} tag
> Currently only initial header resources will take {{}} 
> into account



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6620) @Deprecated classes/methods need to be removed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712566#comment-16712566
 ] 

ASF GitHub Bot commented on WICKET-6620:


GitHub user solomax opened a pull request:

https://github.com/apache/wicket/pull/344

[WICKET-6620] deprecated classes/methods are removed



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/wicket WICKET-6620-remove-deprecated

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/wicket/pull/344.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #344


commit 4b09e371b0a59ff2d093d1236afbf66ee7874402
Author: Maxim Solodovnik 
Date:   2018-12-07T09:52:19Z

[WICKET-6620] deprecated classes/methods are removed




> @Deprecated classes/methods need to be removed
> --
>
> Key: WICKET-6620
> URL: https://issues.apache.org/jira/browse/WICKET-6620
> Project: Wicket
>  Issue Type: Task
>  Components: wicket
>Affects Versions: 9.0.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 9.0.0
>
>
> @Deprecated classes/methods need to be removed
> 1) Drop all `@Deprecated(since = "8.0", forRemoval = true)` from master
> 2) Drop all marked as @Deprecated in wicket7 from master



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WICKET-6617) Header contribution ignore

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WICKET-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706411#comment-16706411
 ] 

ASF GitHub Bot commented on WICKET-6617:


Github user svenmeier commented on a diff in the pull request:

https://github.com/apache/wicket/pull/343#discussion_r238106752
  
--- Diff: 
wicket-core/src/main/java/org/apache/wicket/markup/html/internal/HtmlHeaderContainer.java
 ---
@@ -161,19 +161,19 @@ public final void onComponentTagBody(MarkupStream 
markupStream, ComponentTag ope
final StringResponse response = new StringResponse();
getRequestCycle().setResponse(response);
 
-   IHeaderResponse headerResponse = getHeaderResponse();
-   if (!response.equals(headerResponse.getResponse()))
-   {
-   
getRequestCycle().setResponse(headerResponse.getResponse());
-   }
+   try (IHeaderResponse headerResponse = 
getHeaderResponse()) {
+   if 
(!response.equals(headerResponse.getResponse()))
+   {
+   
getRequestCycle().setResponse(headerResponse.getResponse());
+   }
 
-   // Render the header sections of all components on the 
page
-   AbstractHeaderRenderStrategy.get().renderHeader(this,
-   new HeaderStreamState(markupStream, openTag), 
getPage());
+   // Render the header sections of all components 
on the page
+   
AbstractHeaderRenderStrategy.get().renderHeader(this,
+   new HeaderStreamState(markupStream, 
openTag), getPage());
 
-   // Close the header response before rendering the 
header container itself
-   // See https://issues.apache.org/jira/browse/WICKET-3728
-   headerResponse.close();
--- End diff --

Why no close() any longer?


> Header contribution ignore 
> -
>
> Key: WICKET-6617
> URL: https://issues.apache.org/jira/browse/WICKET-6617
> Project: Wicket
>  Issue Type: Bug
>  Components: wicket-core
>Affects Versions: 8.2.0
>Reporter: Maxim Solodovnik
>Assignee: Maxim Solodovnik
>Priority: Major
>
> Components added via AJAX and contributing to  using @Override 
> renderHead ignores  if any



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)