You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2013/03/01 10:09:01 UTC
Re: 404 error in nested ModalWindow IE 7
Hi,
See org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow#getWindowOpenJavaScript().
There is such code:
appendAssignment(buffer, "settings.ie8_src", pageUrl);
which is used in modal.js:
if(Wicket.Browser.isIELessThan9()){
this.content.contentWindow.location.replace(this.settings.ie8_src);
}else{
this.content.contentWindow.location.replace(this.settings.src);
}
I guess this code breaks for you.
I don't have IE 7/8 around to test it.
On Fri, Mar 1, 2013 at 12:43 AM, Jered Myers
<je...@maplewoodsoftware.com>wrote:
> It appears that the request is different between IE7 and Chrome once it
> hits the Jetty server with the inner modal window. modal.js is calling
> window.location.replace in load with the same value no matter what browser
> I am using. The first window in the Quickstart has a location of
> "./wicket/bookmarkable/com.qs.**NestedModals.**OuterModalContent" and the
> second modal is missing "wicket/bookmarkable" and is only
> "./com.qs.NestedModals.**InnerModalContent". I didn't mount anything (no
> changes in the Application class). The original problem was on a Tomcat6
> server and I tried several versions of Jetty and didn't see a change. I
> did find that if I mount the content page in the Quickstart the problem is
> resolved; however, this is not fixing my primary application. It appears
> that the mappers are not able to locate the page for the class.
>
> Please help if you can.
>
>
> On 02/26/2013 04:47 PM, Jered Myers wrote:
>
>> I am attaching a Quickstart that replicates the problem.
>>
>> On 02/25/2013 09:48 AM, Jered Myers wrote:
>>
>>> I put a break point in CompoundRequestMapper at line 149 (the mapRequest
>>> function). Here are the results of request.getURL.toString():
>>> IE7:
>>> - wicket/page?8 (first ModalWindow)
>>> - page?9 (nested ModalWindow)
>>>
>>> Chrome, IE9 (browser IE7, document IE7):
>>> - wicket/page?8 (first ModalWindow)
>>> - wicket/page?9 (nested ModalWindow)
>>>
>>> I will keep digging. Any help is appreciated!
>>>
>>> On 02/25/2013 09:17 AM, Jered Myers wrote:
>>>
>>>> I do see this in my log if I turn on DEBUG in log4j:
>>>> [08:43:03] DEBUG [org.apache.wicket.request.**mapper.CompoundRequestMapper]
>>>> - No compatible mapper found for URL 'page?6'
>>>> [08:43:03] DEBUG [org.apache.wicket.request.**cycle.RequestCycle] - No
>>>> suitable handler found for URL page?6, falling back to container to process
>>>> this request
>>>>
>>>> I don't see that message when I run in Chrome.
>>>>
>>>> On 02/25/2013 09:13 AM, Jered Myers wrote:
>>>>
>>>>> It looks like it was a bug fixed in a 1.5 release candidate (
>>>>> https://issues.apache.org/**jira/browse/WICKET-3982<https://issues.apache.org/jira/browse/WICKET-3982>).
>>>>> The example in my link (http://www.wicket-library.**
>>>>> com/wicket-examples/ajax/**modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>)
>>>>> appears to be using Wicket 1.5.9, so it should be fixed in that code and it
>>>>> isn't. I am replicating the problem in my own code using Wicket 6.5. I am
>>>>> going to keep digging, but I am suspicious that tests may have been done
>>>>> using the developer tools in IE9. I know that using the IE9 developer
>>>>> tools and changing the document and browser modes will not replicate the
>>>>> problem.
>>>>>
>>>>> On 02/23/2013 04:53 AM, Martin Grigorov wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> There was such issue before but as far as I remember it was fixed.
>>>>>> Look in Jira. There is also a special code for IE7/8 in
>>>>>> ModalWindow.java
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 23, 2013 at 2:40 AM, Jered Myers
>>>>>> <je...@maplewoodsoftware.com>**wrote:
>>>>>>
>>>>>> The same problem happens in IE 8. Using development mode (F12) in
>>>>>>> IE9+ to
>>>>>>> lower the browser version will not replicate the problem.
>>>>>>>
>>>>>>>
>>>>>>> On 02/22/2013 03:23 PM, Jered Myers wrote:
>>>>>>>
>>>>>>> Wicket 6.5
>>>>>>>>
>>>>>>>> I am getting a 404 error in IE 7 when I open a ModalWindow in a
>>>>>>>> ModalWindow. Both windows use page creators. Has anybody run into
>>>>>>>> this
>>>>>>>> before? The code works fine in Firefox, Chrome, and lE9+. This
>>>>>>>> replicates
>>>>>>>> in the Wicket examples if you use the "Show modal dialog with a
>>>>>>>> page" and
>>>>>>>> then "Open another modal dialog" @ http://www.wicket-library.com/**
>>>>>>>> ** <http://www.wicket-library.com/**>
>>>>>>>> wicket-examples/ajax/modal-****window<http://www.wicket-**
>>>>>>>> library.com/wicket-examples/**ajax/modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------****----------------------------**--**---------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>>>>>> <us...@wicket.apache.org>
>>>>>>> >
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: 404 error in nested ModalWindow IE 7
Posted by Jered Myers <je...@maplewoodsoftware.com>.
This problem is not replicating in Wicket 1.4.21.
On 03/01/2013 09:36 AM, Jered Myers wrote:
> I added this problem to JIRA.
>
> https://issues.apache.org/jira/browse/WICKET-5071
>
> On 03/01/2013 08:29 AM, Jered Myers wrote:
>> The page is stateless, so it has the same value being set for
>> settings.ie8_src and settings.src in getWindowOpenJavaScript(). It
>> seems that only pages with setStatelessHint(false) hit the second
>> path in the code...
>>
>> IRequestHandler handler = new
>> RenderPageRequestHandler(new PageProvider(page));
>>
>> pageUrl = requestCycle.urlFor(handler);
>> String ie8_pageUrl =
>> requestCycle.getUrlRenderer().renderRelativeUrl(
>> requestCycle.mapUrlFor(handler));
>> appendAssignment(buffer, "settings.ie8_src",
>> ie8_pageUrl);
>>
>> When I set the stateless hint to false, the value is the same for
>> pageUrl and ie8_pageUrl. I would expect it to be different as that
>> makes having two URLs for window.location pointless. My guess is
>> that I am not replicating the reason for the two different settings
>> or there is a bug.
>>
>> I will add this as a bug in JIRA and clean up my notes to clarify my
>> testing results.
>>
>> On 03/01/2013 01:09 AM, Martin Grigorov wrote:
>>> Hi,
>>>
>>> See
>>> org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow#getWindowOpenJavaScript().
>>> There is such code:
>>> appendAssignment(buffer, "settings.ie8_src", pageUrl);
>>>
>>> which is used in modal.js:
>>>
>>> if(Wicket.Browser.isIELessThan9()){
>>> this.content.contentWindow.location.replace(this.settings.ie8_src);
>>> }else{
>>> this.content.contentWindow.location.replace(this.settings.src);
>>> }
>>>
>>> I guess this code breaks for you.
>>>
>>> I don't have IE 7/8 around to test it.
>>>
>>>
>>> On Fri, Mar 1, 2013 at 12:43 AM, Jered Myers
>>> <je...@maplewoodsoftware.com>wrote:
>>>
>>>> It appears that the request is different between IE7 and Chrome
>>>> once it
>>>> hits the Jetty server with the inner modal window. modal.js is
>>>> calling
>>>> window.location.replace in load with the same value no matter what
>>>> browser
>>>> I am using. The first window in the Quickstart has a location of
>>>> "./wicket/bookmarkable/com.qs.**NestedModals.**OuterModalContent"
>>>> and the
>>>> second modal is missing "wicket/bookmarkable" and is only
>>>> "./com.qs.NestedModals.**InnerModalContent". I didn't mount
>>>> anything (no
>>>> changes in the Application class). The original problem was on a
>>>> Tomcat6
>>>> server and I tried several versions of Jetty and didn't see a
>>>> change. I
>>>> did find that if I mount the content page in the Quickstart the
>>>> problem is
>>>> resolved; however, this is not fixing my primary application. It
>>>> appears
>>>> that the mappers are not able to locate the page for the class.
>>>>
>>>> Please help if you can.
>>>>
>>>>
>>>> On 02/26/2013 04:47 PM, Jered Myers wrote:
>>>>
>>>>> I am attaching a Quickstart that replicates the problem.
>>>>>
>>>>> On 02/25/2013 09:48 AM, Jered Myers wrote:
>>>>>
>>>>>> I put a break point in CompoundRequestMapper at line 149 (the
>>>>>> mapRequest
>>>>>> function). Here are the results of request.getURL.toString():
>>>>>> IE7:
>>>>>> - wicket/page?8 (first ModalWindow)
>>>>>> - page?9 (nested ModalWindow)
>>>>>>
>>>>>> Chrome, IE9 (browser IE7, document IE7):
>>>>>> - wicket/page?8 (first ModalWindow)
>>>>>> - wicket/page?9 (nested ModalWindow)
>>>>>>
>>>>>> I will keep digging. Any help is appreciated!
>>>>>>
>>>>>> On 02/25/2013 09:17 AM, Jered Myers wrote:
>>>>>>
>>>>>>> I do see this in my log if I turn on DEBUG in log4j:
>>>>>>> [08:43:03] DEBUG
>>>>>>> [org.apache.wicket.request.**mapper.CompoundRequestMapper]
>>>>>>> - No compatible mapper found for URL 'page?6'
>>>>>>> [08:43:03] DEBUG
>>>>>>> [org.apache.wicket.request.**cycle.RequestCycle] - No
>>>>>>> suitable handler found for URL page?6, falling back to container
>>>>>>> to process
>>>>>>> this request
>>>>>>>
>>>>>>> I don't see that message when I run in Chrome.
>>>>>>>
>>>>>>> On 02/25/2013 09:13 AM, Jered Myers wrote:
>>>>>>>
>>>>>>>> It looks like it was a bug fixed in a 1.5 release candidate (
>>>>>>>> https://issues.apache.org/**jira/browse/WICKET-3982<https://issues.apache.org/jira/browse/WICKET-3982>).
>>>>>>>>
>>>>>>>> The example in my link (http://www.wicket-library.**
>>>>>>>> com/wicket-examples/ajax/**modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>)
>>>>>>>>
>>>>>>>> appears to be using Wicket 1.5.9, so it should be fixed in that
>>>>>>>> code and it
>>>>>>>> isn't. I am replicating the problem in my own code using
>>>>>>>> Wicket 6.5. I am
>>>>>>>> going to keep digging, but I am suspicious that tests may have
>>>>>>>> been done
>>>>>>>> using the developer tools in IE9. I know that using the IE9
>>>>>>>> developer
>>>>>>>> tools and changing the document and browser modes will not
>>>>>>>> replicate the
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> On 02/23/2013 04:53 AM, Martin Grigorov wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> There was such issue before but as far as I remember it was
>>>>>>>>> fixed.
>>>>>>>>> Look in Jira. There is also a special code for IE7/8 in
>>>>>>>>> ModalWindow.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 23, 2013 at 2:40 AM, Jered Myers
>>>>>>>>> <je...@maplewoodsoftware.com>**wrote:
>>>>>>>>>
>>>>>>>>> The same problem happens in IE 8. Using development mode
>>>>>>>>> (F12) in
>>>>>>>>>> IE9+ to
>>>>>>>>>> lower the browser version will not replicate the problem.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 02/22/2013 03:23 PM, Jered Myers wrote:
>>>>>>>>>>
>>>>>>>>>> Wicket 6.5
>>>>>>>>>>> I am getting a 404 error in IE 7 when I open a ModalWindow in a
>>>>>>>>>>> ModalWindow. Both windows use page creators. Has anybody
>>>>>>>>>>> run into
>>>>>>>>>>> this
>>>>>>>>>>> before? The code works fine in Firefox, Chrome, and lE9+. This
>>>>>>>>>>> replicates
>>>>>>>>>>> in the Wicket examples if you use the "Show modal dialog with a
>>>>>>>>>>> page" and
>>>>>>>>>>> then "Open another modal dialog" @
>>>>>>>>>>> http://www.wicket-library.com/**
>>>>>>>>>>> ** <http://www.wicket-library.com/**>
>>>>>>>>>>> wicket-examples/ajax/modal-****window<http://www.wicket-**
>>>>>>>>>>> library.com/wicket-examples/**ajax/modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------****----------------------------**--**---------
>>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>>>>>>>>> <us...@wicket.apache.org>
>>>>>>>>>>
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**---------
>>>>>
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: 404 error in nested ModalWindow IE 7
Posted by Jered Myers <je...@maplewoodsoftware.com>.
I added this problem to JIRA.
https://issues.apache.org/jira/browse/WICKET-5071
On 03/01/2013 08:29 AM, Jered Myers wrote:
> The page is stateless, so it has the same value being set for
> settings.ie8_src and settings.src in getWindowOpenJavaScript(). It
> seems that only pages with setStatelessHint(false) hit the second path
> in the code...
>
> IRequestHandler handler = new
> RenderPageRequestHandler(new PageProvider(page));
>
> pageUrl = requestCycle.urlFor(handler);
> String ie8_pageUrl =
> requestCycle.getUrlRenderer().renderRelativeUrl(
> requestCycle.mapUrlFor(handler));
> appendAssignment(buffer, "settings.ie8_src",
> ie8_pageUrl);
>
> When I set the stateless hint to false, the value is the same for
> pageUrl and ie8_pageUrl. I would expect it to be different as that
> makes having two URLs for window.location pointless. My guess is that
> I am not replicating the reason for the two different settings or
> there is a bug.
>
> I will add this as a bug in JIRA and clean up my notes to clarify my
> testing results.
>
> On 03/01/2013 01:09 AM, Martin Grigorov wrote:
>> Hi,
>>
>> See
>> org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow#getWindowOpenJavaScript().
>> There is such code:
>> appendAssignment(buffer, "settings.ie8_src", pageUrl);
>>
>> which is used in modal.js:
>>
>> if(Wicket.Browser.isIELessThan9()){
>> this.content.contentWindow.location.replace(this.settings.ie8_src);
>> }else{
>> this.content.contentWindow.location.replace(this.settings.src);
>> }
>>
>> I guess this code breaks for you.
>>
>> I don't have IE 7/8 around to test it.
>>
>>
>> On Fri, Mar 1, 2013 at 12:43 AM, Jered Myers
>> <je...@maplewoodsoftware.com>wrote:
>>
>>> It appears that the request is different between IE7 and Chrome once it
>>> hits the Jetty server with the inner modal window. modal.js is calling
>>> window.location.replace in load with the same value no matter what
>>> browser
>>> I am using. The first window in the Quickstart has a location of
>>> "./wicket/bookmarkable/com.qs.**NestedModals.**OuterModalContent"
>>> and the
>>> second modal is missing "wicket/bookmarkable" and is only
>>> "./com.qs.NestedModals.**InnerModalContent". I didn't mount
>>> anything (no
>>> changes in the Application class). The original problem was on a
>>> Tomcat6
>>> server and I tried several versions of Jetty and didn't see a
>>> change. I
>>> did find that if I mount the content page in the Quickstart the
>>> problem is
>>> resolved; however, this is not fixing my primary application. It
>>> appears
>>> that the mappers are not able to locate the page for the class.
>>>
>>> Please help if you can.
>>>
>>>
>>> On 02/26/2013 04:47 PM, Jered Myers wrote:
>>>
>>>> I am attaching a Quickstart that replicates the problem.
>>>>
>>>> On 02/25/2013 09:48 AM, Jered Myers wrote:
>>>>
>>>>> I put a break point in CompoundRequestMapper at line 149 (the
>>>>> mapRequest
>>>>> function). Here are the results of request.getURL.toString():
>>>>> IE7:
>>>>> - wicket/page?8 (first ModalWindow)
>>>>> - page?9 (nested ModalWindow)
>>>>>
>>>>> Chrome, IE9 (browser IE7, document IE7):
>>>>> - wicket/page?8 (first ModalWindow)
>>>>> - wicket/page?9 (nested ModalWindow)
>>>>>
>>>>> I will keep digging. Any help is appreciated!
>>>>>
>>>>> On 02/25/2013 09:17 AM, Jered Myers wrote:
>>>>>
>>>>>> I do see this in my log if I turn on DEBUG in log4j:
>>>>>> [08:43:03] DEBUG
>>>>>> [org.apache.wicket.request.**mapper.CompoundRequestMapper]
>>>>>> - No compatible mapper found for URL 'page?6'
>>>>>> [08:43:03] DEBUG [org.apache.wicket.request.**cycle.RequestCycle]
>>>>>> - No
>>>>>> suitable handler found for URL page?6, falling back to container
>>>>>> to process
>>>>>> this request
>>>>>>
>>>>>> I don't see that message when I run in Chrome.
>>>>>>
>>>>>> On 02/25/2013 09:13 AM, Jered Myers wrote:
>>>>>>
>>>>>>> It looks like it was a bug fixed in a 1.5 release candidate (
>>>>>>> https://issues.apache.org/**jira/browse/WICKET-3982<https://issues.apache.org/jira/browse/WICKET-3982>).
>>>>>>>
>>>>>>> The example in my link (http://www.wicket-library.**
>>>>>>> com/wicket-examples/ajax/**modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>)
>>>>>>>
>>>>>>> appears to be using Wicket 1.5.9, so it should be fixed in that
>>>>>>> code and it
>>>>>>> isn't. I am replicating the problem in my own code using Wicket
>>>>>>> 6.5. I am
>>>>>>> going to keep digging, but I am suspicious that tests may have
>>>>>>> been done
>>>>>>> using the developer tools in IE9. I know that using the IE9
>>>>>>> developer
>>>>>>> tools and changing the document and browser modes will not
>>>>>>> replicate the
>>>>>>> problem.
>>>>>>>
>>>>>>> On 02/23/2013 04:53 AM, Martin Grigorov wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> There was such issue before but as far as I remember it was fixed.
>>>>>>>> Look in Jira. There is also a special code for IE7/8 in
>>>>>>>> ModalWindow.java
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 23, 2013 at 2:40 AM, Jered Myers
>>>>>>>> <je...@maplewoodsoftware.com>**wrote:
>>>>>>>>
>>>>>>>> The same problem happens in IE 8. Using development mode
>>>>>>>> (F12) in
>>>>>>>>> IE9+ to
>>>>>>>>> lower the browser version will not replicate the problem.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/22/2013 03:23 PM, Jered Myers wrote:
>>>>>>>>>
>>>>>>>>> Wicket 6.5
>>>>>>>>>> I am getting a 404 error in IE 7 when I open a ModalWindow in a
>>>>>>>>>> ModalWindow. Both windows use page creators. Has anybody run
>>>>>>>>>> into
>>>>>>>>>> this
>>>>>>>>>> before? The code works fine in Firefox, Chrome, and lE9+. This
>>>>>>>>>> replicates
>>>>>>>>>> in the Wicket examples if you use the "Show modal dialog with a
>>>>>>>>>> page" and
>>>>>>>>>> then "Open another modal dialog" @
>>>>>>>>>> http://www.wicket-library.com/**
>>>>>>>>>> ** <http://www.wicket-library.com/**>
>>>>>>>>>> wicket-examples/ajax/modal-****window<http://www.wicket-**
>>>>>>>>>> library.com/wicket-examples/**ajax/modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------****----------------------------**--**---------
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>>>>>>>> <us...@wicket.apache.org>
>>>>>>>>>
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ------------------------------**------------------------------**---------
>>>>
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: 404 error in nested ModalWindow IE 7
Posted by Jered Myers <je...@maplewoodsoftware.com>.
The page is stateless, so it has the same value being set for
settings.ie8_src and settings.src in getWindowOpenJavaScript(). It
seems that only pages with setStatelessHint(false) hit the second path
in the code...
IRequestHandler handler = new
RenderPageRequestHandler(new PageProvider(page));
pageUrl = requestCycle.urlFor(handler);
String ie8_pageUrl =
requestCycle.getUrlRenderer().renderRelativeUrl(
requestCycle.mapUrlFor(handler));
appendAssignment(buffer, "settings.ie8_src", ie8_pageUrl);
When I set the stateless hint to false, the value is the same for
pageUrl and ie8_pageUrl. I would expect it to be different as that
makes having two URLs for window.location pointless. My guess is that I
am not replicating the reason for the two different settings or there is
a bug.
I will add this as a bug in JIRA and clean up my notes to clarify my
testing results.
On 03/01/2013 01:09 AM, Martin Grigorov wrote:
> Hi,
>
> See org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow#getWindowOpenJavaScript().
> There is such code:
> appendAssignment(buffer, "settings.ie8_src", pageUrl);
>
> which is used in modal.js:
>
> if(Wicket.Browser.isIELessThan9()){
> this.content.contentWindow.location.replace(this.settings.ie8_src);
> }else{
> this.content.contentWindow.location.replace(this.settings.src);
> }
>
> I guess this code breaks for you.
>
> I don't have IE 7/8 around to test it.
>
>
> On Fri, Mar 1, 2013 at 12:43 AM, Jered Myers
> <je...@maplewoodsoftware.com>wrote:
>
>> It appears that the request is different between IE7 and Chrome once it
>> hits the Jetty server with the inner modal window. modal.js is calling
>> window.location.replace in load with the same value no matter what browser
>> I am using. The first window in the Quickstart has a location of
>> "./wicket/bookmarkable/com.qs.**NestedModals.**OuterModalContent" and the
>> second modal is missing "wicket/bookmarkable" and is only
>> "./com.qs.NestedModals.**InnerModalContent". I didn't mount anything (no
>> changes in the Application class). The original problem was on a Tomcat6
>> server and I tried several versions of Jetty and didn't see a change. I
>> did find that if I mount the content page in the Quickstart the problem is
>> resolved; however, this is not fixing my primary application. It appears
>> that the mappers are not able to locate the page for the class.
>>
>> Please help if you can.
>>
>>
>> On 02/26/2013 04:47 PM, Jered Myers wrote:
>>
>>> I am attaching a Quickstart that replicates the problem.
>>>
>>> On 02/25/2013 09:48 AM, Jered Myers wrote:
>>>
>>>> I put a break point in CompoundRequestMapper at line 149 (the mapRequest
>>>> function). Here are the results of request.getURL.toString():
>>>> IE7:
>>>> - wicket/page?8 (first ModalWindow)
>>>> - page?9 (nested ModalWindow)
>>>>
>>>> Chrome, IE9 (browser IE7, document IE7):
>>>> - wicket/page?8 (first ModalWindow)
>>>> - wicket/page?9 (nested ModalWindow)
>>>>
>>>> I will keep digging. Any help is appreciated!
>>>>
>>>> On 02/25/2013 09:17 AM, Jered Myers wrote:
>>>>
>>>>> I do see this in my log if I turn on DEBUG in log4j:
>>>>> [08:43:03] DEBUG [org.apache.wicket.request.**mapper.CompoundRequestMapper]
>>>>> - No compatible mapper found for URL 'page?6'
>>>>> [08:43:03] DEBUG [org.apache.wicket.request.**cycle.RequestCycle] - No
>>>>> suitable handler found for URL page?6, falling back to container to process
>>>>> this request
>>>>>
>>>>> I don't see that message when I run in Chrome.
>>>>>
>>>>> On 02/25/2013 09:13 AM, Jered Myers wrote:
>>>>>
>>>>>> It looks like it was a bug fixed in a 1.5 release candidate (
>>>>>> https://issues.apache.org/**jira/browse/WICKET-3982<https://issues.apache.org/jira/browse/WICKET-3982>).
>>>>>> The example in my link (http://www.wicket-library.**
>>>>>> com/wicket-examples/ajax/**modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>)
>>>>>> appears to be using Wicket 1.5.9, so it should be fixed in that code and it
>>>>>> isn't. I am replicating the problem in my own code using Wicket 6.5. I am
>>>>>> going to keep digging, but I am suspicious that tests may have been done
>>>>>> using the developer tools in IE9. I know that using the IE9 developer
>>>>>> tools and changing the document and browser modes will not replicate the
>>>>>> problem.
>>>>>>
>>>>>> On 02/23/2013 04:53 AM, Martin Grigorov wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> There was such issue before but as far as I remember it was fixed.
>>>>>>> Look in Jira. There is also a special code for IE7/8 in
>>>>>>> ModalWindow.java
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 23, 2013 at 2:40 AM, Jered Myers
>>>>>>> <je...@maplewoodsoftware.com>**wrote:
>>>>>>>
>>>>>>> The same problem happens in IE 8. Using development mode (F12) in
>>>>>>>> IE9+ to
>>>>>>>> lower the browser version will not replicate the problem.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/22/2013 03:23 PM, Jered Myers wrote:
>>>>>>>>
>>>>>>>> Wicket 6.5
>>>>>>>>> I am getting a 404 error in IE 7 when I open a ModalWindow in a
>>>>>>>>> ModalWindow. Both windows use page creators. Has anybody run into
>>>>>>>>> this
>>>>>>>>> before? The code works fine in Firefox, Chrome, and lE9+. This
>>>>>>>>> replicates
>>>>>>>>> in the Wicket examples if you use the "Show modal dialog with a
>>>>>>>>> page" and
>>>>>>>>> then "Open another modal dialog" @ http://www.wicket-library.com/**
>>>>>>>>> ** <http://www.wicket-library.com/**>
>>>>>>>>> wicket-examples/ajax/modal-****window<http://www.wicket-**
>>>>>>>>> library.com/wicket-examples/**ajax/modal-window<http://www.wicket-library.com/wicket-examples/ajax/modal-window>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------****----------------------------**--**---------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apa**che.org<http://apache.org>
>>>>>>>> <us...@wicket.apache.org>
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org