317750 - cellardoor.za.net - TinyMCE/mosCE Editor does not connect to the text fields of the Input form

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Volker Schmidt]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051116 Camino/1.0b1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051116 Camino/1.0b1+

The editor is only opened in the first of the two text fields and does not connect to the input of the text field. If you type any changes it will not be applied to the contents of the text field. The same procedure works with Camino up to version 1.0a1 (including).

Reproducible: Always

Steps to Reproduce:
1. Go to the "Demo" page given in the URL and login as publisher
2. Klick to the "Edit" icon of a News text
3. wait until the Javascript is loaded

Actual Results:  
After going to edit, theere are the text fields filled with HTML source. Then the editor starts but only in the upper text field (Initial text). the lower filed does not start an editor. In the upper editor there is no contents in the editor window.
If you make changes this changes will not be updated to the text.

Expected Results:  
Expected results visible with Camino 1.0a1:
The editor is opened in both text fields. The HTML contents of the text fields is translated into a RTF (I thin) and displayed in a WYSIWYG-form. After saving the text, the changes will be introduced into the News article.

It seems to be connected with a similar bug in Firefox (Bug # 314967 ). The behaviour is similar.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is really a Core bug of some sort (or a problem with the site's code, perhaps); should this go to Editor or somewhere else in Core?

Volker, if you could go through the Camino nightly builds between 1.0a1 and 1.0b1 and figure out exactly when this broke, that would be very useful.  You want builds from directories ending in -1.0/ from http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/

Comment 2

[Volker Schmidt]

(In reply to comment #1)
> This is really a Core bug of some sort (or a problem with the site's code,
> perhaps); should this go to Editor or somewhere else in Core?
> 
> Volker, if you could go through the Camino nightly builds between 1.0a1 and
> 1.0b1 and figure out exactly when this broke, that would be very useful.  You
> want builds from directories ending in -1.0/ from
> http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/

Hallo Smokey, it was a big surprise for me but there is really one version of Camino in the nightly build where Java and Javascript works! :-)
But from beginning:
Version 2005093004 v1.0a1+ from 9/30/2005 is the last version where the javascript editor works (with one requester that the script is responding to slow , but if you click to "Continue" all works perfect. Version 2005100404 v1.0a1+ from 10/4/2005 is the first version where the Javascript is broken:
Additionaly Version 2005093004 is one of the first versions where Java applets works (Java applets work also with 1.0b1). But is is nearly the only version where our companies Java applets works cause they need Javascript and Java ...
Cause I found a similar behaviour in the Bug reports from Firefox Windows with the newest versions I think that this problem is not originated from the Camino part ... 

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Another regression when we didn't have builds for a few days :-(

Regression window: http://tinyurl.com/apnmh

There are just too many possible bugs in that window (splitwindow stuff, JS, DOM)....  

Volker, could you please check the Firefox nightlies around those dates to see if we can get a more precise window on when this broke?  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and the directories in question are the ones that end in -mozilla1.8/ 

Then we can send this bug to the right component and person responsible....  Thanks!

Comment 4

[Volker Schmidt]

(In reply to comment #3)
> Volker, could you please check the Firefox nightlies around those dates to see
> if we can get a more precise window on when this broke? 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and the directories in
> question are the ones that end in -mozilla1.8/ 

Good idea but what to do with files: firefox-1.4.1.en-US.mac.partial.2005100106-2005100206.mar I don't know how to handle. I don't find packages (or binaries) for the firefox nightly build. dmg-files I find only for the "latest".

> Then we can send this bug to the right component and person responsible.... 

If I had tested it earlier ... (but I have a good news: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051130 Firefox/1.5 has the same problem ... Is there anything who can test the nightly builds between September 30th and october 4th?! or who know what to do with this .mar-Files?!

> Thanks!
> 

Comment 5

[Simon Fraser [no longer active]]

There are .dmg files for Firefox (go to a different mozilla1.8 dir for the day).

I wonder if this is JEP-related?

Comment 6

[Volker Schmidt]

(In reply to comment #5)
> There are .dmg files for Firefox (go to a different mozilla1.8 dir for the
> day).

For some days: In the directory  2005-10-03-06-mozilla1.8/  there was a dmg-file. The version "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051003 Firefox/1.4.1" has the same bug -- so we are one day shorter to the date. In directories between the 30. Sep 2005 and 3. Oct 2005 I didn't found dmg-Files (sorry). (I cannot find a DMG file in September anywhere ...)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The .dmgs are missing from ftp.mozilla.org and the mirrors.  Maybe you can find them at archive.mozilla.org:
http://archive.mozilla.org/pub/firefox/nightly/

Comment 8

[Volker Schmidt]

(In reply to comment #7)
> The .dmgs are missing from ftp.mozilla.org and the mirrors.  Maybe you can find
> them at archive.mozilla.org:
> http://archive.mozilla.org/pub/firefox/nightly/

OK now the further feature list: 
after and including version: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1 from 10/1/2005 -> Javascript broken, Java OK

last working version: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050930 Firefox/1.4 from 9/30/2005 -> Javascript OK, Java OK

I hope this helps finding the reason.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

New regression window based on the Fx builds: http://tinyurl.com/bk33g

Simon, any better ideas on who's responsible and where in the Core this should go?  One of Blake's checkins?

(Volker, thanks for all the legwork!)

Comment 10

[Samuel Sidler (old account; do not CC)]

If it's anything like Midas (and I think it is), this should go in Core -> Editor.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So how do I actually reproduce it?  The pages involved are huge and the directions in comment 0 too vague to make sense (e.g., where is this "edit icon" I'm supposed to click)?

Further, the expect and actual results don't make much sense to me.  How do I tell in 2 seconds of looking whether I'm seeing this bug?

Comment 12

[Samuel Sidler (old account; do not CC)]

(In reply to comment #11)
> So how do I actually reproduce it?  The pages involved are huge and the
> directions in comment 0 too vague to make sense (e.g., where is this "edit
> icon" I'm supposed to click)?
> 
> Further, the expect and actual results don't make much sense to me.  How do I
> tell in 2 seconds of looking whether I'm seeing this bug?
> 

1. Login on http://www.cellardoor.za.net/mosce/demo/ as publisher:publisher. 
2. Select the "edit" icon on any of the articles on the main page (some are already being edited so you have to try til you find one that's "open").
3. The page that opens should show two wysiwyg editors one above the other. It only shows one. The bottom where you can see the error.

Note: I can't reproduce this on FF 1.5/Win. This appears to be Mac-only.

Comment 13

[Samuel Sidler (old account; do not CC)]

(In reply to comment #11)
> (e.g., where is this "edit icon" I'm supposed to click)?

The edit icon is above each article in the main content area. It is to the right of the title and is a pencil on a piece of paper. It only shows after logging in.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So with a Linux build I see two editors, but they don't show the same thing as a September 30 build shows...

Comment 15

[Samuel Sidler (old account; do not CC)]

(In reply to comment #14)
> So with a Linux build I see two editors, but they don't show the same thing as
> a September 30 build shows...
> 

I see two editors in the Windows build that show different content (as it should be), but the same implementation of the editors is the same for both. The implementation looks the same in both the 9/30 build and FF 1.5 final.

Comment 16

[Boris Zbarsky [:bzbarsky]]

That sounds _really_ odd.... I guess I'll try to narrow down when this broke... :(

Comment 17

[Boris Zbarsky [:bzbarsky]]

So mrbkap tracked this down.  The site has separate branches for IE and Gecko, and the Gecko branch relies on document.title persisting across the document being cleared by document.open.  After bug 304388 that is no longer the case (to prevent nasty spoofing attacks).

Given all that, I suggest evangelizing the website...

Samuel, could you check whether the issue you see on Mac is the same as what Blake and I were seeing?  Does commenting out http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/document/src/nsHTMLDocument.cpp&rev=3.649&mark=2023#2023 make things better?

Comment 18

[Samuel Sidler (old account; do not CC)]

(In reply to comment #17)
> Samuel, could you check whether the issue you see on Mac is the same as what
> Blake and I were seeing?  Does commenting out
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/document/src/nsHTMLDocument.cpp&rev=3.649&mark=2023#2023
> make things better?
> 

Yes, that fixes it. I'm still not clear why this shows fine on FF 1.5/Win...

Should this be moved to Evangelism or duped to bug 317725? (I'm thinking it's its own bug because Joomla and Mambo are separate now...)

Comment 19

[Boris Zbarsky [:bzbarsky]]

> I'm still not clear why this shows fine on FF 1.5/Win...

No idea; might depend on what their "is IE" test is.

> Should this be moved to Evangelism or duped to bug 317725? 

I'd put them both in evangelism, I think.

Comment 20

[Samuel Sidler (old account; do not CC)]

(In reply to comment #19)
> I'd put them both in evangelism, I think.
> 

-> Tech Evangelism

Comment 21

[Blake Kaplan (:mrbkap) (inactive)]

So, in parallel with bug 317725, this bug should be aboug getting cellardoor.za to update their TinyMCE installation.

Comment 22

[Karl Dubost💡 :karlcow]

www.cellardoor.za.net/mosce/content/view/14/29/

→ whois cellardoor.za.net
No match for "CELLARDOOR.ZA.NET".

Welll… :) issue solved.