Dang! I thought the app was doing a
continueToOriginalDestination();
to return from the login page to the home page at "/" but it wasn't so there's
no problem with continueToOriginalDestination().
It was actually doing a setResponse(new HomePage()); from a
the LogonPage that had no
Found it
It seems FireFox does have an issue with the actions that start with ..?
The page I was going to (localhost/myapp) had a mount path at "/"
i.e.
@MountPath(value = "/", alt = "/home")
Now this mount path annotation was also in the test app that didn't exhibit the
problem but
I found an interesting difference between the quickstart that works and the app
that doesn't work in FF:
The action parameter of the form is generated with a .. prefix instead of ./
So in the app that doesn't work:
The form's action attribute is defined as:
I'm trying to create a quickstart but so far it doesn't reproduce the problem
in the main app - all day I've been pulling in aspects of the main app in an
attempt to replicate the exact scenario.
I have now managed to get the quickstart to produce JS in the same order that
the main app does so
Is there any kind of defer or async on any of these JS script resources?
Maybe you want to publish the quickstart?
- Ursprüngliche Mail -
> Von: "Chris Colman"
> An: users@wicket.apache.org
> Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> Betreff: RE:
The cut down app that works fine in FireFox also has both jquery.js and
bootstrap.js so this probably means that it's ok to have both of these together.
./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-1.12.4.js
Thanks Korginian - I'll check out that theory.
All the JS included are done automatically by a combo of Wicket itself and the
Wicket-Bootstrap project which I'm using in this app.
Is there an easy way to tell which component is contributing which .js to the
"header" (which is actually in the
Hi Chris,
can it be that you have 2 instances of jQuery in your page? - bootstrap.js
often comes with embedded jQuery and then you would overwrite the wicket one
with the bootstrap one, that will lead to problems where you dont get notfied
at all. I know this from foundation / sites, where you
I've made some progress. I have created a cut down app that produces a
similar page to the troublesome one in the large app that exhibits the
problem - except I can't make the cut down app exhibit the problem yet
;)
... but I have found a suble difference between the two apps:
It seems to be
I disabled all plugins and add-ons but it still happens.
I'll try to create a quickstart that reproduces the problem.
> -Original Message-
> From: Andrea Del Bene [mailto:an.delb...@gmail.com]
> Sent: Saturday, 7 October 2017 12:33 AM
> To: users@wicket.apache.org
> Subject: Re:
I'm running Wicket with wicket-bootstrap but I wouldn't think that would
cause any issues.
> -Original Message-
> From: Andrea Del Bene [mailto:an.delb...@gmail.com]
> Sent: Saturday, 7 October 2017 12:33 AM
> To: users@wicket.apache.org
> Subject: Re: AjaxFormComponentUpdatingBehavior
Hi,
I've tried your code but everything works fine. Maybe your FF has an add-on
that causes the problem ?
On Fri, Oct 6, 2017 at 1:21 PM, Chris Colman
wrote:
> I also tried it without the leading 'on' in 'onchange'
>
> > -Original Message-
> > From: Chris
I also tried it without the leading 'on' in 'onchange'
> -Original Message-
> From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> Sent: Friday, 6 October 2017 10:12 PM
> To: users@wicket.apache.org
> Subject: AjaxFormComponentUpdatingBehavior not triggering ListChoice
model
>
13 matches
Mail list logo