Closed Bug 295544 Opened 15 years ago Closed 15 years ago
Expose more design
Mode options to web apps
Expose more designMode options to web apps It turns out that a priviledged script using designMode can configure more of the behaviors of designMode, including: * The ability to turn off object resizing. It would be great to have access to nsIHTMLEditor.objectResizingEnabled. * The ability to turn off the table editing UI. It would be great to have access to nsIHTMLInlineTableEditor.inlineTableEditingEnabled. I know that we don't want to expose these interfaces to untrusted script, but perhaps we could reflect some of these options on nsIDOMNSHTMLDocument alongside the other design mode methods and attributes. I think a simple "flags" like attribute that can be used to enable/disable capabilities per document would be nice. It looks like it should be easy enough to implement this in nsHTMLDocument.cpp. Does anyone have any suggestions on what the API should look like?
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta3
s/nsIHTMLEditor/nsIHTMLObjectResizer/ in comment #0
I think I'd be ok with a flags attribute (named designModeFlags or something, perhaps?).
bz: yeah, that's sort of the API i was considering. do we have any other examples of DOM APIs (for the web) exposing a flags-like getter and setter?
I spoke with jst over IRC about this API, and he suggested that it would be better to leverage the execCommand API. We can basically follow what he did to implement insertBrOnReturn. So, my plan is to add boolean commands named: enableObjectResizing enableInlineTableEditing Does this sound good to everyone?
There appears to be a bug that prevents disabling object resizing UI after it has been shown, but that is a separate bug IMO. Glazman has sent me a patch that should help with that situation. For now, I want to just get this basic support in, since it makes it possible to do the following: doc.designMode = "on"; doc.execCommand("enableObjectResizing", false, "false"); doc.execCommand("enableInlineTableEditing", false, "false"); Then, things seem to work as expected.
Comment on attachment 187056 [details] [diff] [review] v1 patch: using execCommand sr=jst
Attachment #187056 - Flags: superreview?(jst) → superreview+
I'd really like to see this patch make the Deer Park Alpha 2 train if possible.
Comment on attachment 187056 [details] [diff] [review] v1 patch: using execCommand r=brade (thanks!)
Attachment #187056 - Flags: review?(brade) → review+
for the record, IBM has used a similar patch I made for them a while ago. Ask mkaply.
https://bugzilla.mozilla.org/show_bug.cgi?id=294687 add EnableAbsolutePositioning and it's the same patch and more :)
So, should I add the absolute positioning control to this patch then?
That would be awesome if you can do that. Then I can just dupe my bug to this one.
I don't want this patch to miss the DPA2 train, so how about if I add absolute positioning as a followup patch? Feel free to mark the other as a dupe.
*** Bug 294687 has been marked as a duplicate of this bug. ***
Attachment #187056 - Flags: approval1.8b3? → approval1.8b3+
The v1 patch is in on the trunk. Leaving this bug open to add the absolute positioning option.
mkaply: "cmd_absPos" already exists for design mode, so i think this bug can actually be resolved fixed.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
mkaply: actually, it looks like cmd_absPos is not reflected by nsHTMLDocument::execCommand :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
mkaply: I can't figure out what disabling abs positioning in midas provides the web app developer. There doesn't seem to be any UI that would allow the user to abs position something. Am I missing something?
marking FIXED per discussion with mkaply over IRC.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.