You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2006/02/22 13:25:23 UTC

Forms broken on IE

Hi,

With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
This happens whenever I click somewhere on the page (doesn't matter
where: in a blank area or an input field).

The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
variable is undefined:

  onMouseUp: function(e){
    this.mouseDownX = null;
    this.mouseDownY = null;
    this._dragTriggered = false;
    var _this = this;
    e.preventDefault();   <=== e undefined

Maybe some of you who follow up dojo development know if this is already
fixed or if the problem is caused by us.

TIA

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Re: Forms broken on IE

Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2006-02-23 at 13:43 +0100, Sylvain Wallez wrote:
> Bruno Dumon wrote:
> > Hi,
> >
> > With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
> > This happens whenever I click somewhere on the page (doesn't matter
> > where: in a blank area or an input field).
> >
> > The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
> > variable is undefined:
> >
> >   onMouseUp: function(e){
> >     this.mouseDownX = null;
> >     this.mouseDownY = null;
> >     this._dragTriggered = false;
> >     var _this = this;
> >     e.preventDefault();   <=== e undefined
> >
> > Maybe some of you who follow up dojo development know if this is already
> > fixed or if the problem is caused by us.
> >   
> 
> This not a problem in Dojo, but a bug in Matt Kruses's PopupWindow class 
> that wasn't properly chaining window.onload when there's an existing 
> handler, as is the case with Dojo.
> 
> I fixed it when committing the Dojo stuff [1]
> 
> Sylvain
> 
> [1] 
> http://svn.apache.org/viewcvs.cgi/cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/resources/mattkruse-lib/PopupWindow.js?rev=379087&r1=367689&r2=379087
> 

Hmmm, I still have this error. I was first testing on Windows 2000 (with
latest IE6) but now verified it's the same on Windows XP. This is with
an up to date checkout from this morning. Nobody else seeing this?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Re: Forms broken on IE

Posted by Sylvain Wallez <sy...@apache.org>.
Bruno Dumon wrote:
> Hi,
>
> With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
> This happens whenever I click somewhere on the page (doesn't matter
> where: in a blank area or an input field).
>
> The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
> variable is undefined:
>
>   onMouseUp: function(e){
>     this.mouseDownX = null;
>     this.mouseDownY = null;
>     this._dragTriggered = false;
>     var _this = this;
>     e.preventDefault();   <=== e undefined
>
> Maybe some of you who follow up dojo development know if this is already
> fixed or if the problem is caused by us.
>   

This not a problem in Dojo, but a bug in Matt Kruses's PopupWindow class 
that wasn't properly chaining window.onload when there's an existing 
handler, as is the case with Dojo.

I fixed it when committing the Dojo stuff [1]

Sylvain

[1] 
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/resources/mattkruse-lib/PopupWindow.js?rev=379087&r1=367689&r2=379087

-- 
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member


Re: Forms broken on IE

Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 23.02.2006 13:44, Sylvain Wallez wrote:
>
>> I plan to spend quite some time on this next week, adding a few 
>> features that I need and ensuring all works fine both in Ajax and 
>> non-Ajax modes.
>
> Does it already make sense from you POV to talk about a release date? 
> Or is it to uncertain?

 From my POV, it *has* to be finished next week because of schedule 
constraints. So it makes sense.

Sylvain

-- 
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member


Re: Forms broken on IE

Posted by Joerg Heinicke <jo...@gmx.de>.
On 23.02.2006 13:44, Sylvain Wallez wrote:

> I plan to spend quite some time on this next week, adding a few features 
> that I need and ensuring all works fine both in Ajax and non-Ajax modes.

Does it already make sense from you POV to talk about a release date? Or 
is it to uncertain?

Jörg

Re: Forms broken on IE

Posted by Sylvain Wallez <sy...@apache.org>.
Bruno Dumon wrote:
> I think we can mark them both stable. It's not like the Ajax
> functionality will be removed again in the future, and from the user's
> mailing list it seems many people are already relying on it.
>
> But as Sylvain pointed out, since he just rewrote that part, it might be
> better to wait a few weeks for the release so that it can get some more
> testing.
>   

I plan to spend quite some time on this next week, adding a few features 
that I need and ensuring all works fine both in Ajax and non-Ajax modes.

Sylvain

-- 
Sylvain Wallez
http://bluxte.net
Apache Software Foundation Member


Re: Forms broken on IE

Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2006-02-23 at 11:10 +0100, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> > Hi,
> > 
> > With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
> > This happens whenever I click somewhere on the page (doesn't matter
> > where: in a blank area or an input field).
> > 
> > The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
> > variable is undefined:
> > 
> >   onMouseUp: function(e){
> >     this.mouseDownX = null;
> >     this.mouseDownY = null;
> >     this._dragTriggered = false;
> >     var _this = this;
> >     e.preventDefault();   <=== e undefined
> > 
> > Maybe some of you who follow up dojo development know if this is already
> > fixed or if the problem is caused by us.
> > 
> Such issues really raise the question, Ralph has asked earlier one: Does
> it make sense
> that a stable forms block heavily depends on such an unstable Ajax
> block? I would be great, if the forms block could be used without ajax
> and ajax is an optional part. So we can mark forms stable without having
> to worry about ajax stuff. If we are not going this way and are tying
> those blocks heavily together (like they are today) then we should not
> mark the forms block stable and wait for that until the ajax block is
> stable as well.

I think we can mark them both stable. It's not like the Ajax
functionality will be removed again in the future, and from the user's
mailing list it seems many people are already relying on it.

But as Sylvain pointed out, since he just rewrote that part, it might be
better to wait a few weeks for the release so that it can get some more
testing.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Re: Forms broken on IE

Posted by Carsten Ziegeler <cz...@apache.org>.
Bruno Dumon wrote:
> Hi,
> 
> With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
> This happens whenever I click somewhere on the page (doesn't matter
> where: in a blank area or an input field).
> 
> The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
> variable is undefined:
> 
>   onMouseUp: function(e){
>     this.mouseDownX = null;
>     this.mouseDownY = null;
>     this._dragTriggered = false;
>     var _this = this;
>     e.preventDefault();   <=== e undefined
> 
> Maybe some of you who follow up dojo development know if this is already
> fixed or if the problem is caused by us.
> 
Such issues really raise the question, Ralph has asked earlier one: Does
it make sense
that a stable forms block heavily depends on such an unstable Ajax
block? I would be great, if the forms block could be used without ajax
and ajax is an optional part. So we can mark forms stable without having
to worry about ajax stuff. If we are not going this way and are tying
those blocks heavily together (like they are today) then we should not
mark the forms block stable and wait for that until the ajax block is
stable as well.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/