Closed Bug 197253 Opened 21 years ago Closed 20 years ago

Implement midas (HTMLArea) for camino

Categories

(Camino Graveyard :: Page Layout, defect)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino0.9

People

(Reporter: bugzilla, Assigned: Usul)

References

(
URL
)

Details

(Whiteboard: midas)

Attachments

(2 files, 1 obsolete file)

Complete patch
30.31 KB, patch
me
: review+
jaas
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review
diff against the config file
600 bytes, patch
Details | Diff | Splinter Review 
need to implement midas for camino. (reassign as needed.)
QA Contact: winnie → sairuh
Blocks: 197865
Whiteboard: midas
Depends on: 208132
*** Bug 208389 has been marked as a duplicate of this bug. ***
*** Bug 221980 has been marked as a duplicate of this bug. ***
No longer blocks: 197865
*** Bug 236874 has been marked as a duplicate of this bug. ***
What seems to be the problme in implementing this? Mike any idea?
any progress for this old bug?
*** Bug 241236 has been marked as a duplicate of this bug. ***
Adding (HTMLArea) to description, to try to reduce dupes.
Summary: implement midas for camino → Implement midas (HTMLArea) for camino
yea, i did do a search for htmlarea and didn't find anything. i'm sorry i didn't
know it was midas i was looking for.
I recently got htmlarea to work with Camino.

I compiled Camino (succesfully both once the trunk, as on the MOZILLA_1_7_BRANCH

with the following in .mozconfig:

ac_add_options --enable-default-toolkit=cocoa
ac_add_options --disable-tests
ac_add_options --enable-crypto
ac_add_options --disable-mailnews
ac_add_options --disable-ldap
ac_add_options --disable-accessibility
ac_add_options --disable-jsd
ac_add_options --disable-mathml
ac_add_options --disable-xpinstall
ac_add_options
--enable-extensions=cookie,xmlextras,universalchardet,transformiix,typeaheadfind
ac_add_options --with-system-zlib
ac_add_options --enable-single-profile
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O2

after succesful building, following a hint on the camino list, I copied the
composerlib into the Camino package:
cp -p editor/composer/src/libcomposer.dylib
camino/build/Camino.app/Contents/MacOS/components/

and most seems to work (both with the mozilla.org demo, as with an
implementation of itools-htmlarea) very well and very speedy.
still, more extensive tests have to be made...

a test build is available at
http://www.yellowspace.net/camino_tests/Camino_08b_Midas.dmg.gz
How much data (mb's) will be added when we package this with Camino? We don't
really want a huge package for download.
omg...you would really not include awesome functionality like this because of
download size? this feature is sorely lacking in camino. please include it.
Jasper (comment 10)--I'd guess it's far less than 1/4 of a meg.  From my
optimized mozilla build from a month ago, the composer dylib was 164352 bytes. 
It's possible this could / would be smaller in a Camino build depending on build
options/flags.

I *think* you also need to add a stylesheet and another text file in a jar where
the editor can find it (needed for image resizing and table resizing).  These
are also tiny.

Someone should reassign this bug to themselves and get this fixed.  :-)
Keywords: helpwanted
fyi...

the build's sizes (running package) here are as follows:

Camino 0.8b-2004-05-31 (mozilla.org nightly build, 
ac_add_options --enable-plaintext-editor-only)
package: 20.130.418 bytes 

Camino 0.8b-2004-06-01  
(own checkout, with midas)
package: 23.320.218 bytes 

libcomposer.dylib is 163.692 bytes.

Ifcourse it's Mikes call but package size is why we didn't ship with it in the
first place. I think the size of adding this would be ok. But remeber that we
just today added XSLT support.

Sounds really cool that everything works now :)
With my mozconfig: 
ac_add_options --enable-default-toolkit=cocoa 
ac_add_options --disable-tests 
ac_add_options --enable-crypto 
ac_add_options --disable-mailnews 
ac_add_options --disable-ldap 
ac_add_options --disable-accessibility 
ac_add_options --disable-jsd 
ac_add_options --disable-mathml 
ac_add_options --disable-xpinstall 
ac_add_options
--enable-extensions=cookie,xmlextras,universalchardet,transformiix,typeaheadfind 
ac_add_options --with-system-zlib 
ac_add_options --enable-single-profile 
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk 
ac_add_options --disable-debug 
ac_add_options --enable-optimize=-O2

I compiled today's cvs from the beta branch and then copied libcomposer.dylib to
the right directory, but it's not working for me.  Did you do a clean build?  I
tried your build and it works great.
> I compiled today's cvs from the beta branch and then copied libcomposer.dylib to
> the right directory, but it's not working for me.  Did you do a clean build?
> I tried your build and it works great.

yes, i did make a clean build

(lucky as i am to access a g5/bi-1.8 to do it, where the complete mozilla+camino
build takes about 35 mins with mk_add_options MOZ_MAKE_FLAGS=-j4)

i basically followed the instructions on
http://www.mozilla.org/ports/fizzilla/ChimChim.html

but with
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co
-rMOZILLA_1_7_BRANCH mozilla/camino.mk

and
omitting ac_add_options --enable-plaintext-editor-only
from my .mozconfig.

and then, 
cp -p editor/composer/src/libcomposer.dylib
camino/build/Camino.app/Contents/MacOS/components/

miscellaneous:

OS: Mac OS X 10.3.4, XCode Tools 1.1, Fink 0.20.1, orbit 0.5.17-16, orbit-dev
0.5.17-16, glib 1.2.10-18, and the SharedMenusCocoa Framework from 
ftp://ftp.url-manager.com/pub/SharedMenusCocoa.dmg.bin


Now that Safari is on the scene, I don't think package size should be our top priority. There's no way in 
hell we're ever going to come close to Safari's package size so we need to differentiate in other areas, 
like offering XSLT support, midas support, and XML prettyprint, IMO. I'm not saying we should bloat it 
out, but put in enough cool features that Safari doesn't have so that people can justify downloading it 
even if it is bigger. Otherwise we're just a Safari clone to the average Mac user.
Actually, Camino’s package size is not a whole lot larger than Safari’s
(20.3MB vs 14.6MB), and might even be smaller if you consider that Camino has
Gecko as part of the package, but Safari’s package size does not include the
size of KHTML which is part of the OS. ;)
BTW, Dave Hyatt just announced that Safari will soon support HTML editing using contenteditable, 
execCommand, and all that good stuff. I'm still hoping Camino will beat them to it though :)
Addition... :

to have all the widgets working correctly (particularly the table widget of
itools-htmlarea), not only libcomposer.dylib has to be copied into
camino/build/Camino.app/Contents/MacOS/components/
but also the complete contents of editor/composer/src/* into 
camino/build/Camino.app/Contents/MacOS/res/
L., with that in mind, is your size figure in comment 13 still accurate?
*** Bug 257595 has been marked as a duplicate of this bug. ***
So, what is the status of this bug?  Will this be compiled into the next Camino
release?  If not, what is stopping it, and how can I help?  HTMLArea support is
a HUGE necessity for me as it’s being adopted into more and more sites. 
Additionally, a project I work on utilizes it, and I have to switch into firefox
(or custom compile camino) in order to get this working.  If it’s size you’re
worried about (though this seems like a terribly silly concern at the expense of
this important feature), can you offer an official version that includes this as
an option?  Or an add-on?
This issue is purely a packaging issue.  I don't have access to fix the
makefiles and such to package the composer dylib.  I'm pretty sure it works to
just build the composer dylib and put it in the Camino.app next to the editor
dylib (long ago I did that and it worked).  There are several css files that
should be included too.

Reassign bug to pinkerton for reassignment since I don't have a tree or
privileges (but I'd be happy to review the patch).
Assignee: brade → pinkerton
does this work yet for the static build? If so, we need to get a patch up so
that people can test it.
Status: NEW → ASSIGNED
Target Milestone: --- → Camino0.9
Assignee: pinkerton → qa-mozilla
Status: ASSIGNED → NEW
brade: who took away your mozilla account? just have leaf change the email on
yours. once a contributor, always a contributor ;) heck, even pchen still has his ;)
Attached patch Patch bringing Midas support (obsolete) — — Splinter Review 
19921674 is the size of Camino compiled with -O2 and midas support.
libcomposer.a weights 175024 bytes.
composer.xpt weights 690 bytes.
txmgr.xpt weights 1258 bytes.

Instructions for reviewers :
in .mozconfig remove the ac_add_options --enable-plaintext-editor-only line.
Attachment #160044 - Flags: review?
That's a reasonable size :) Cool that you looked into this.
Comment on attachment 160044 [details] [diff] [review]
Patch bringing Midas support

This is not a complete patch; you also need to include some css files so image
resizing and other things will function correctly.

You'll need:

http://lxr.mozilla.org/seamonkey/source/editor/composer/src/res/EditorOverride.
css

You may want to include some of the gifs from that directory also (I'm not sure
which Firefox includes).
Brade could you give me a second URL to test ? I saw no problem with the midas demo.
Here is a more complete midas test page:
http://www.angelblade.com/midas/tester.html
Very much related to this bug: document.designMode should be unset if the
browser doesn't support designMode, which is the basis of content editable
features. Camino 0.8 lies, and does some weird things as a result with a page
which has an HTMLArea.
we should fix that setting for 082. can someone hack up a patch that sets that
pref that we can land on the branch and stop lying about it there?
(In reply to comment #32)
> Very much related to this bug: document.designMode should be unset if the
> browser doesn't support designMode, which is the basis of content editable

Does being at off marks the document unset ? or do you really mean unset ?
Attachment #160044 - Flags: review?
(In reply to comment #34)
>
> Does being at off marks the document unset ? or do you really mean unset ?
> 

(W3CDOM && document.designMode) should return false.

However, to enable and disable designMode (in browsers which have it available),
one would call it doc.designMode = "On" or doc.designMode = "Off".  I presume
browsers that *don't* support it should not even have the variable defined.
*** Bug 264130 has been marked as a duplicate of this bug. ***
(In reply to comment #33)
> we should fix that setting for 082. can someone hack up a patch that sets that
> pref that we can land on the branch and stop lying about it there?

It's not a pref. Its a build bug, some stuff needs to be #ifdef in the composer
code to fix this.
Comment on attachment 160044 [details] [diff] [review]
Patch bringing Midas support

uncomplete patch. Need to add more .js files, a couple of images too. Will keep
you posted when I think it's ready.
Attachment #160044 - Attachment is obsolete: true
Before posting my new version of the patch I would like people to test. I've
taken into account Brade's comments. You can find a camino with Midas at
http://softkid.nerim.net/camino.zip. Comment here of send ma a mail if you think
the build is incomplete etc ...
(In reply to comment #39)

Ludovic: almost all the files inside the application package seem to be gzipped, the package is broken 
and upon trying to launch, it shows "unknown error -10810". After unpacking the files, Camino crashes 
during the launch. 

Config: Mac OS X 10.3.5, tested with and without existing profile, re-downloaded the archive, same 
effect. Is it just me or is the package broken?
(In reply to comment #40)
> effect. Is it just me or is the package broken?

Broken packages because I messed up with gzip. This is now fixed. Sorry for the
broken download - Please retry

(In reply to comment #41)

> Broken packages because I messed up with gzip. This is now fixed. Sorry for the
> broken download - Please retry

Works fine - performed a short test with an intranet app, tested briefly against
http://www.angelblade.com/midas/tester.html

No problems for me - lovely, I'll keep this until the patch shows up in the nightlies or until it's getting 
on my nerves if it crashes too much. 

THANK YOU, you've made my day ;-))

Works with http://www.mozilla.org/editor/midasdemo/ and
http://www.angelblade.com/midas/tester.html but no way to make it work in Moodle
(see http://moodle.org/), though it works in Firefox.
(In reply to comment #43)
> http://www.angelblade.com/midas/tester.html but no way to make it work in Moodle
> (see http://moodle.org/), though it works in Firefox.

Do you have an installation somewhere Where I could test ?

(In reply to comment #44)
You could use this one: http://school.fri-tic.ch/~moodletest/ (just click on
"Start now by creating a new account!") and get in. You can mail me if you want
some help in there.
OK, I set up a Moodle account. Where am I supposed to go to test Midas? Please provide detailed 
instructions.
Here are the steps to test it on a Moodle:

1. Got enrolled in a course. On the site http://school.fri-tic.ch/~moodletest/,
the course "Fourmis noires et fourmis rouges" is the way to go.
2. Open a forum (e.g. the forum "Testing Midas")
3. Reply to a post or begin a new discussion.
4. Midas should appear in the "Message" window (it works in Firefox).
OK, here's a test page based on the Moodle code:
http://www.angelblade.com/midas/moodletest.html
The midas part itself seems to work fine. I'm guessing the problem lies in the midas-detection that the 
page does.
With build provided in comment #39, test case of comment #48 does work though
the Moodle doesn't. Are you sure this is a test case for the Moodle problem?
That's the Midas code taken directly from the Moddle site. So the midas editor that Moodle uses does 
work in the Camino test-build. The problem lies in Moodle's midas-support detection. If you go to the 
page in Camino, Moodle doesn't even try to use midas, that's the problem. I've noticed that SiteMason's 
CMS system has the same problem - midas works, but midas detection doesn't. Maybe this is related to 
comment #32.
OK, here's what I found out re SiteMason: Because of the bug mentioned in comment #32, SiteMason 
specifically looks for 'Camino' in the user-agent screen and disables midas for Camino (regardless of 
whether Camino supports midas or not). I imagine the same thing is going on on Moodle.
(In reply to comment #32)
> Very much related to this bug: document.designMode should be unset if the
> browser doesn't support designMode, which is the basis of content editable
> features. Camino 0.8 lies, and does some weird things as a result with a page
> which has an HTMLArea.

this is bug #197317
Depends on: 197317
Keywords: helpwanted
What I'm hearing here is that the midas builds are working properly once they
get to the enhanced forms. If that's the case and we're happy enough testing has
been done should this be patched and evangelism bugs filed on the sites sniffing
for camino explicitly (and maybe relnoted)?

If we're this close to patching midas changes to bug 197317 don't really seem to
be all that important anymore. It would have been nice months and months ago so
that authors wouldn't have had to code special cases for Camino, but once Camino
builds by default with Midas the designMode flag will infact be matching with
the capabilities of the build.

(In reply to comment #54)
> If we're this close to patching midas changes to bug 197317 don't really seem to
> be all that important anymore. It would have been nice months and months ago so
> that authors wouldn't have had to code special cases for Camino, but once Camino
> builds by default with Midas the designMode flag will infact be matching with
> the capabilities of the build.

Are you saying Midas will be included in the next release in the .8 tree?  Even
so, what if a user complies Camino w/o midas support in the future (you can
specify it with a --option during ./configure, can you not?).  When a person
does that, the browser shouldn't lie about support.  If you can optionally not
include it, it should also not report that support is enabled.  As a developer,
this makes things impossible to sniff out (now, my sniffing is, if Camino, if
less than .9, disable midas- but people could have custom builds which lie about
support, so what the *#$ do I do about that?).


Re comment #52: I looked thoroughly the Moodle code and found out that the
problem has nothing to do with Camino :-)

Moodle sniffes Camino and for some reason deactivates Midas. I'll evangelize the
Moodle devs to make this change.

For those interested, the code to comment out in Moodle is in the
"lib/moodlelib.php" file, lines 3540-3543. I made the change for the site
http://school.fri-tic.ch/~moodletest/ and Midas works with the build of comment #39.
re: comment 55 - I don't know timeline, haven't been following the project much
lately, just watching a few important (to me) bugs. I'm also not downplaying the
importance of bug 197317 which should have been fixed months ago so that folks
like you didn't feel the need to code special cases for camino, or private
builds of firefox, or anything else. Its more the dependancy that I was trying
to downplay. If *this* bug will indeed be fixed for 0.8.x or 0.9 instead of 1.0
or later then for Camino the other bug isn't as important. Ultimately we need
both bugs fixed, but more immediately from a Camino specific POV I think its one
or the other.
(In reply to comment #57)

> or later then for Camino the other bug isn't as important. Ultimately we need
> both bugs fixed, but more immediately from a Camino specific POV I think its one
> or the other.

Midas will be 0.9 which will be released when ready. O.8 which will have a 082
would be better with out the property being set hnece the relationship beteween
bugs. Evangeliusm is better when you say that Camino behaves properly, whatever
recent version is used be it the stable or dev releases.

Once the patch land there will be evangelism to do anyway.

This bug is NOT dependent on bug 197317! Are you guys paying attention are not? I said Moodle 
doesn't work because of bug 197317. I didn't say midas doesn't work because of bug 197317. I'm 
removing the dependency.

This patch is golden IMO. Let's plug it in, crank it out, and slap a sticker on it.
No longer depends on: 197317
(In reply to comment #59)
> This bug is NOT dependent on bug 197317! Are you guys paying attention are not? 
It does. Because the sofware sniffs-out Camino because Camino has desig.mode
set, so they need to sniff it out. Midas is for 0.9. We are going to release
0.8.2, how do you want to evangelisze to the developers of those packages that
now camino behaves correctly, when 0.9 is going to be released at an unknown
date, we need that bug to be fixed for the 0.8.x series, until that midas
support won't be properly implemented in camino - it is not atm because we have
a property defined that should not be.


I understand how the two bugs are related, but there is no dependency here. Regardless of bug 
197317, this patch works and should be checked in. Whether or not Camino 0.8.2 indentifies its midas-
support correctly is a separate issue. Here's what we need to do:
1. Check in this patch for 0.9 (since it seems to be ready)
2. Fix bug 197317 for Camino 0.8.2
3. Evangelize for webmaster to stop filtering out Camino
Attached patch Complete patch — — Splinter Review 

    
  

        Attachment #164187 -
        Flags: review?(me)

    
    

    
  
Comment on attachment 164187 [details] [diff] [review]
Complete patch

I've tested this with both the URL on the bug and one from the comments, and
this seems to work as well as it does in FireFox. The only problem I see is
this, when I try to copy or paste:
2004-11-08 07:20:21.344 Camino[15078] JS error: uncaught exception:
[Exception... "Access to XPConnect service denied"  code: "1011" nsresult:
"0x805303f3 (NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED)"  location:
"http://www.angelblade.com/midas/tester.html Line: 195"]

2004-11-08 07:20:27.908 Camino[15078] JS error: uncaught exception:
[Exception... "Access to XPConnect service denied"  code: "1011" nsresult:
"0x805303f3 (NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED)"  location:
"http://www.angelblade.com/midas/tester.html Line: 195"]

Since I see the same in FireFox, I'm not worrying about it.
r=me@mollyandgeoff.com

        Attachment #164187 -
        Flags: review?(me) → review+

    
    

    
  
Comment to whoever reviews this next: this patch may not apply to a project
that's ever been opened with xcode. If you've got a tree you've been using, you
may need to check out a fresh copy of the project. Also, this does not patch
mozilla/camino/config/mozconfig

You'll need to go in there and remove the line 
ac_add_options --enable-plaintext-editor-only

This should probably be part of the patch, as that is now part of our CVS.

Still r=me@mollyandgeoff.com, but that should be fixed :-)

    
    

    
  
Re Comment #63: I seem to remember copying and pasting in midas being disabled at some point for 
security reasons. Not sure about the details though.

    
  

        Attachment #164187 -
        Flags: review?(joshmoz)

    
    

    
  
(In reply to comment #63)
> (From update of attachment 164187 [details] [diff] [review])
> The only problem I see is...when I try to copy or paste:

Of course, you mean using the copy/paste buttons.  Command+C and Command+V
should always work for copy/paste.  As for the buttons: JS access to the
clipboard could be a security risk (for instance, if you copied something to the
clipboard that you didn't want to be public, and some page with JS snatched
it)... however, IIRC, there should be an option in Mozilla/Firefox/Browsers with
Midas support somewhere to enable JS access to the clipboard, and/or limit it to
certain sites.  I don't see this anywhere in Camino... perhaps we should add it?

    
    

    
  
This is implemented using the following settings that must be put into the user.js

user_pref("capability.policy.policynames", "allowclipboard");
user_pref("capability.policy.allowclipboard.sites", "http://www.yoursite.com");
user_pref("capability.policy.allowclipboard.Clipboard.cutcopy", "allAccess");
user_pref("capability.policy.allowclipboard.Clipboard.paste", "allAccess");

    
    

    
  
(In reply to comment #68)
> This is implemented using the following settings that must be put into the user.js

For usability sake, is there a bug out there to make a GUI for JS prefs?  I
mean, IE has it...

    
    

    
  
Doesn't work for me. Midas just doesn't do anything. Once I got this error:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIDOMNSHTMLDocument.designMode]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame :: http://www.angelblade.com/midas/htmlarea.js :: anonymous
:: line 680"  data: no]

    
  

        Attachment #164187 -
        Flags: review?(joshmoz)

    
  

        Attachment #164187 -
        Flags: superreview?(pinkerton)

    
    

    
  
Comment on attachment 164187 [details] [diff] [review]
Complete patch

rs=pink

        Attachment #164187 -
        Flags: superreview?(pinkerton) → superreview+

    
    

    
  
landed
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
Will this fix be present in release 0.8.2?

    
    

    
  
(In reply to comment #73)
> Will this fix be present in release 0.8.2?

NO - 0.8.2 is a bug fix, security fix. No new major faetures in 0.8.2

    
    

    
  
Will this be in the 8.2 release. If not, when?

    
    

    
  
(In reply to comment #75)
> Will this be in the 8.2 release. If not, when?

In 0.9 or the nigthlies.


    
    

    
  
tested with 2005011808-trunk camino bits on 10.3.7.

overall, this works, but found some issues --are they already filed?

a. cut, copy, paste icon buttons in the test url don't work --although cmd+X,
cmd+C and cmd+V do work fine.

b. after trying the commands in the 2nd formatting toolbar (same sample url
above), the caret (and focus) within the midas editing area is lost. need to hit
Tab or reclick in the editing area again.
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 292425 has been marked as a duplicate of this bug. ***

    
    

    
  
to #77 "sairuh (on vacation)",

that's not a problem from Camino, that is a design-decision implementen by
gecko, it is the same on the other browser (firefox, mozilla suite).

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: