Closed Bug 197253 Opened 19 years ago Closed 17 years ago
Implement midas (HTMLArea) for camino
need to implement midas for camino. (reassign as needed.)
*** Bug 208389 has been marked as a duplicate of this bug. ***
*** Bug 221980 has been marked as a duplicate of this bug. ***
*** 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. :-)
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:firstname.lastname@example.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 ;)
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.
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 ?
(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
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
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 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 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. email@example.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 firstname.lastname@example.org, 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.
(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]
Comment on attachment 164187 [details] [diff] [review] Complete patch rs=pink
Attachment #164187 - Flags: superreview?(pinkerton) → superreview+
Status: NEW → RESOLVED
Closed: 17 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.