Re: RedirectToUrlException seems to be broken in FF
Maybe it is not allowed to redirect from Ajax handler? On Sat, Oct 7, 2017 at 1:07 PM, Maxim Solodovnik wrote: > Here is the quick start: https://github.com/solomax/ajax-download > > On Sat, Oct 7, 2017 at 12:40 PM, Maxim Solodovnik > wrote: >> Thanks for the clarifications Martin, >> >> According to [1] 'Ajax-Location' is being set instead of 'Location' >> (due to redirect happens on ajax button click) >> This works as expected in Chrome but fails in FF :((( >> >> Will continue debugging and will try to create quickstart >> >> >> [1] >> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java#L273 >> >> On Fri, Oct 6, 2017 at 9:59 PM, Martin Grigorov wrote: >>> Maybe I was not clear enough. >>> HttpServletResponse#sendRedirect() is supposed to set the Location header, >>> i.e. Tomcat/Jetty. >>> >>> The other status codes do it manually because #sendRedirect() would >>> override the status code. >>> >>> IMO you should ask at Tomcat forums why the Location is not being set. >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> https://twitter.com/mtgrigorov >>> >>> On Fri, Oct 6, 2017 at 4:10 PM, Maxim Solodovnik >>> wrote: >>> This code: https://github.com/apache/wicket/blob/master/wicket- request/src/main/java/org/apache/wicket/request/http/handler/ RedirectRequestHandler.java Has special handling of moved temporary WBR, Maxim (from mobile, sorry for the typos) On Oct 6, 2017 20:05, "Maxim Solodovnik" wrote: > The status is being set correctly, Location is not being set :( > > WBR, Maxim > (from mobile, sorry for the typos) > > On Oct 6, 2017 20:04, "Martin Grigorov" wrote: > >> Hi, >> >> Isn't this something that the web container should do for us ? >> >> javax.servlet.http.HttpServletResponse#sendRedirect() sets the status to >> 302, that's the reason why the others do it "manually". >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Fri, Oct 6, 2017 at 2:18 PM, Maxim Solodovnik >> wrote: >> >> > Hello All, >> > >> > Recently I found RedirectToUrlException is not working in FF (works in >> > Chrome) >> > Redirect URL is being displayed for microsecond, then page is just >> > being refreshed >> > >> > What I found during debugging: >> > In case code is SC_MOVED_TEMPORARILY Location header is not set. >> > >> > FF site [1] clearly states Location should be set >> > >> > Tested on master branch. >> > >> > Should I prepare PR or this is done on purpose? >> > >> > [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302 >> > >> > -- >> > WBR >> > Maxim aka solomax >> > >> > >> >> >> >> -- >> WBR >> Maxim aka solomax > > > > -- > WBR > Maxim aka solomax -- WBR Maxim aka solomax
Re: wicket8 : wickets js/ jquery integration
Is the such option for CSS as well? I have implemented "delayed load" manually since both JS and CSS were reported as "blocking scripts" On Sun, Oct 8, 2017 at 12:25 PM, Martin Grigorov wrote: > On Oct 7, 2017 23:23, "Sven Meier" wrote: > > Hi Korbinian, > > using the "defer" attribute on script tags in the head section seems to be > best practice now: > > > The problem is that the ondomready scripts depend on jquery and wicket-xyz > ones and there is no way to defer them. > > > https://www.shivering-isles.com/the-science-of-loading-javascript/ > > Wicket supports the attribute since https://issues.apache.org/jira > /browse/WICKET-5715 > > Have fun > Sven > > > > Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: > >> Hi, >> >> currently wicket renders all its jQuery and Ajax stuff right into the >> head, and I wonder why. >> Current best practice seems to defer all javascript till the end of the >> page just right before the closing tag to let the browser meanwhile >> get the DOM and do some work and not get blocked by loading resources. So >> wouldnt it maybe with wicket 8 be a good time to change this? >> >> e.g. Do >> >> >> all the stuff >> >> >> >> ajax stuff... >> >> >> >> by default? and since mostly today jQuery is already on the page maybe >> even allow to apply a null at the >> getJavaScriptLibrarySettings().setJQueryReference(null); >> to not have a wicket reference on it at all? Many webapps nowadays tend to >> only have 1 app.js that includes everything as its often build by tools >> like webpack. >> >> Would this be a good or bad idea? >> >> Best, >> >> Korbinian >> >> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right? >> >> -- WBR Maxim aka solomax
Re: wicket8 : wickets js/ jquery integration
Hi Sven, in theory you are right - but with wicket ajax on page you get an inline script like marting said. > The problem is that the ondomready scripts depend on jquery and wicket-xyz > ones and there is no way to defer them. So, you never can defer the jQuery currently as its from wicket itself and same is IMHO for the wicket js files. The only way I can think of is to transfer the inline script into a base64 and embedd it this way: Then the jQuery could be made defered - you can check it here: https://stackoverflow.com/questions/41394983/how-to-defer-inline-javascript However, I'm not sure yet that every browser works with this. So the put to bottom is IMHO still the best way to do it. Or did I miss something here? Also what do you think on allowing to not use the wicket jQuery at all? e.g.: getJavaScriptLibrarySettings().setJQueryReference(null); Anyway, I think wicket should not block the rendering of the page by default, especially as mobile is becoming the 50%+ audience nowadays. Best, Korbinian - Ursprüngliche Mail - > Von: "Sven Meier" > An: dev@wicket.apache.org > Gesendet: Samstag, 7. Oktober 2017 22:22:56 > Betreff: Re: wicket8 : wickets js/ jquery integration > Hi Korbinian, > > using the "defer" attribute on script tags in the head section seems to > be best practice now: > > https://www.shivering-isles.com/the-science-of-loading-javascript/ > > Wicket supports the attribute since > https://issues.apache.org/jira/browse/WICKET-5715 > > Have fun > Sven > > > Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: >> Hi, >> >> currently wicket renders all its jQuery and Ajax stuff right into the head, >> and >> I wonder why. >> >> Current best practice seems to defer all javascript till the end of the page >> just right before the closing tag to let the browser meanwhile get >> the >> DOM and do some work and not get blocked by loading resources. So wouldnt it >> maybe with wicket 8 be a good time to change this? >> >> e.g. Do >> >> >> all the stuff >> >> > src="../wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery.js"> >> >> ajax stuff... >> >> >> >> by default? and since mostly today jQuery is already on the page maybe even >> allow to apply a null at the >> getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket >> reference on it at all? Many webapps nowadays tend to only have 1 app.js that >> includes everything as its often build by tools like webpack. >> >> Would this be a good or bad idea? >> >> Best, >> >> Korbinian >> >> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
Re: wicket8 : wickets js/ jquery integration
Putting header items at the end of is documented here: https://ci.apache.org/projects/wicket/guide/8.x/single.html#_put_javascript_inside_page_body. Like Sven I also personally dislike this kind of habit but we might consider to make the overall configuration easier for it. On 08/10/2017 11:06, Korbinian Bachl wrote: Hi Sven, in theory you are right - but with wicket ajax on page you get an inline script like marting said. The problem is that the ondomready scripts depend on jquery and wicket-xyz ones and there is no way to defer them. So, you never can defer the jQuery currently as its from wicket itself and same is IMHO for the wicket js files. The only way I can think of is to transfer the inline script into a base64 and embedd it this way: Then the jQuery could be made defered - you can check it here: https://stackoverflow.com/questions/41394983/how-to-defer-inline-javascript However, I'm not sure yet that every browser works with this. So the put to bottom is IMHO still the best way to do it. Or did I miss something here? Also what do you think on allowing to not use the wicket jQuery at all? e.g.: getJavaScriptLibrarySettings().setJQueryReference(null); Anyway, I think wicket should not block the rendering of the page by default, especially as mobile is becoming the 50%+ audience nowadays. Best, Korbinian - Ursprüngliche Mail - Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Samstag, 7. Oktober 2017 22:22:56 Betreff: Re: wicket8 : wickets js/ jquery integration Hi Korbinian, using the "defer" attribute on script tags in the head section seems to be best practice now: https://www.shivering-isles.com/the-science-of-loading-javascript/ Wicket supports the attribute since https://issues.apache.org/jira/browse/WICKET-5715 Have fun Sven Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: Hi, currently wicket renders all its jQuery and Ajax stuff right into the head, and I wonder why. Current best practice seems to defer all javascript till the end of the page just right before the closing tag to let the browser meanwhile get the DOM and do some work and not get blocked by loading resources. So wouldnt it maybe with wicket 8 be a good time to change this? e.g. Do all the stuff ajax stuff... by default? and since mostly today jQuery is already on the page maybe even allow to apply a null at the getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket reference on it at all? Many webapps nowadays tend to only have 1 app.js that includes everything as its often build by tools like webpack. Would this be a good or bad idea? Best, Korbinian PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
Re: RedirectToUrlException seems to be broken in FF
Hello All, I have performed deeper investigation and find out this code works as expected in wicket6 But NOT work in wicket7 quickstart: https://github.com/solomax/redirect-to-url wicket7.x branch == wicket 7.9.0 (also not working in 7.9.0) wicket6.x branch == wicket 6.28.0 Steps to reproduce: 1) start quickstart using `mvn jetty:run` 2) click "Redirect to Google" Redirect will happens in Chrome and not happens in FF Wicket code seems to be similar So I guess the issue might be in Jetty/Tomcat, will try to find working scenario/workaround for this On Sun, Oct 8, 2017 at 2:38 PM, Maxim Solodovnik wrote: > Maybe it is not allowed to redirect from Ajax handler? > > On Sat, Oct 7, 2017 at 1:07 PM, Maxim Solodovnik wrote: >> Here is the quick start: https://github.com/solomax/ajax-download >> >> On Sat, Oct 7, 2017 at 12:40 PM, Maxim Solodovnik >> wrote: >>> Thanks for the clarifications Martin, >>> >>> According to [1] 'Ajax-Location' is being set instead of 'Location' >>> (due to redirect happens on ajax button click) >>> This works as expected in Chrome but fails in FF :((( >>> >>> Will continue debugging and will try to create quickstart >>> >>> >>> [1] >>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java#L273 >>> >>> On Fri, Oct 6, 2017 at 9:59 PM, Martin Grigorov >>> wrote: Maybe I was not clear enough. HttpServletResponse#sendRedirect() is supposed to set the Location header, i.e. Tomcat/Jetty. The other status codes do it manually because #sendRedirect() would override the status code. IMO you should ask at Tomcat forums why the Location is not being set. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Oct 6, 2017 at 4:10 PM, Maxim Solodovnik wrote: > This code: > https://github.com/apache/wicket/blob/master/wicket- > request/src/main/java/org/apache/wicket/request/http/handler/ > RedirectRequestHandler.java > > Has special handling of moved temporary > > WBR, Maxim > (from mobile, sorry for the typos) > > On Oct 6, 2017 20:05, "Maxim Solodovnik" wrote: > > > The status is being set correctly, Location is not being set :( > > > > WBR, Maxim > > (from mobile, sorry for the typos) > > > > On Oct 6, 2017 20:04, "Martin Grigorov" wrote: > > > >> Hi, > >> > >> Isn't this something that the web container should do for us ? > >> > >> javax.servlet.http.HttpServletResponse#sendRedirect() sets the status > to > >> 302, that's the reason why the others do it "manually". > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> https://twitter.com/mtgrigorov > >> > >> On Fri, Oct 6, 2017 at 2:18 PM, Maxim Solodovnik > >> wrote: > >> > >> > Hello All, > >> > > >> > Recently I found RedirectToUrlException is not working in FF (works > >> > in > >> > Chrome) > >> > Redirect URL is being displayed for microsecond, then page is just > >> > being refreshed > >> > > >> > What I found during debugging: > >> > In case code is SC_MOVED_TEMPORARILY Location header is not set. > >> > > >> > FF site [1] clearly states Location should be set > >> > > >> > Tested on master branch. > >> > > >> > Should I prepare PR or this is done on purpose? > >> > > >> > [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302 > >> > > >> > -- > >> > WBR > >> > Maxim aka solomax > >> > > >> > > > >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >> >> >> >> -- >> WBR >> Maxim aka solomax > > > > -- > WBR > Maxim aka solomax -- WBR Maxim aka solomax
Re: RedirectToUrlException seems to be broken in FF
This can be work-arounded by using normal, non-ajax submit. On Mon, Oct 9, 2017 at 10:27 AM, Maxim Solodovnik wrote: > Hello All, > > I have performed deeper investigation and find out this code works as > expected in wicket6 > But NOT work in wicket7 > > quickstart: https://github.com/solomax/redirect-to-url > > wicket7.x branch == wicket 7.9.0 (also not working in 7.9.0) > wicket6.x branch == wicket 6.28.0 > > Steps to reproduce: > 1) start quickstart using `mvn jetty:run` > 2) click "Redirect to Google" > Redirect will happens in Chrome and not happens in FF > > Wicket code seems to be similar > So I guess the issue might be in Jetty/Tomcat, will try to find > working scenario/workaround for this > > On Sun, Oct 8, 2017 at 2:38 PM, Maxim Solodovnik wrote: >> Maybe it is not allowed to redirect from Ajax handler? >> >> On Sat, Oct 7, 2017 at 1:07 PM, Maxim Solodovnik >> wrote: >>> Here is the quick start: https://github.com/solomax/ajax-download >>> >>> On Sat, Oct 7, 2017 at 12:40 PM, Maxim Solodovnik >>> wrote: Thanks for the clarifications Martin, According to [1] 'Ajax-Location' is being set instead of 'Location' (due to redirect happens on ajax button click) This works as expected in Chrome but fails in FF :((( Will continue debugging and will try to create quickstart [1] https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java#L273 On Fri, Oct 6, 2017 at 9:59 PM, Martin Grigorov wrote: > Maybe I was not clear enough. > HttpServletResponse#sendRedirect() is supposed to set the Location header, > i.e. Tomcat/Jetty. > > The other status codes do it manually because #sendRedirect() would > override the status code. > > IMO you should ask at Tomcat forums why the Location is not being set. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Fri, Oct 6, 2017 at 4:10 PM, Maxim Solodovnik > wrote: > >> This code: >> https://github.com/apache/wicket/blob/master/wicket- >> request/src/main/java/org/apache/wicket/request/http/handler/ >> RedirectRequestHandler.java >> >> Has special handling of moved temporary >> >> WBR, Maxim >> (from mobile, sorry for the typos) >> >> On Oct 6, 2017 20:05, "Maxim Solodovnik" wrote: >> >> > The status is being set correctly, Location is not being set :( >> > >> > WBR, Maxim >> > (from mobile, sorry for the typos) >> > >> > On Oct 6, 2017 20:04, "Martin Grigorov" wrote: >> > >> >> Hi, >> >> >> >> Isn't this something that the web container should do for us ? >> >> >> >> javax.servlet.http.HttpServletResponse#sendRedirect() sets the status >> to >> >> 302, that's the reason why the others do it "manually". >> >> >> >> Martin Grigorov >> >> Wicket Training and Consulting >> >> https://twitter.com/mtgrigorov >> >> >> >> On Fri, Oct 6, 2017 at 2:18 PM, Maxim Solodovnik >> >> >> >> wrote: >> >> >> >> > Hello All, >> >> > >> >> > Recently I found RedirectToUrlException is not working in FF (works >> >> > in >> >> > Chrome) >> >> > Redirect URL is being displayed for microsecond, then page is just >> >> > being refreshed >> >> > >> >> > What I found during debugging: >> >> > In case code is SC_MOVED_TEMPORARILY Location header is not set. >> >> > >> >> > FF site [1] clearly states Location should be set >> >> > >> >> > Tested on master branch. >> >> > >> >> > Should I prepare PR or this is done on purpose? >> >> > >> >> > [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302 >> >> > >> >> > -- >> >> > WBR >> >> > Maxim aka solomax >> >> > >> >> >> > >> -- WBR Maxim aka solomax >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >> >> >> >> -- >> WBR >> Maxim aka solomax > > > > -- > WBR > Maxim aka solomax -- WBR Maxim aka solomax
