531159 - No documentation on _moz_resizing/_moz_abspos or how to disable it

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P5)

Description

[electronic Max]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: 

My specific problem: I want a content-editable div (whose CONTENTS are editable but whose location on the page is fixed). 

The _moz_resizing attribute seems to enable things to be resized.  But overriding (setting) this attribute in the page's javascript doesn't seem to do anything.

The _moz-resizing and _moz_abspos attributes are not documented ANYWHERE, and therefore it is hard to figure out how to override default behaviors, making these features pretty useless to web developers.

Reproducible: Always

Comment 1

[Victor Costan]

If possible, please stop exhibiting this non-standard behavior! If it's deemed useful, it should be opt-in, not opt-out. 

In order to get rid of _moz_resizing:
    if (document.queryCommandEnabled('enableObjectResizing')) {
      document.execCommand('enableObjectResizing', false, 'false');
    }

I'm not aware of any workaround for _moz_abspos, other than wrapping the contentEditable div with another div, and having the wrapper div take the position: absolute.

Comment 2

[(no longer active)]

These attributes are solely used to make these elements stylable like this: <http://mxr.mozilla.org/mozilla-central/source/layout/style/contenteditable.css#218>.  Does anyone know if there is a better way to do this, ideally in a way that transparent to content?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

A custom, chrome-only, pseudo class should do it. It'd be really cool if we had a chrome-only pseudo class like:

:-moz-internal-property(foo)

which mapped to checking if nsINode::GetProperty mapped to NS_PROPTABLE_PROP_NOT_THERE.

Comment 4

[Boris Zbarsky [:bzbarsky]]

We could implement that, but then every single SetProperty would need to notify the style system or something....

For this particular case, we could just add some event state bits.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Boris: Since this would be an internal selector, I think it'd be fine to make it the responsibility of whoever calls SetProperty to cause whatever style recomputations are needed.

Do we even modify these attributes on rendered elements?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I think it'd be fine to make it the responsibility of whoever calls SetProperty
> to cause whatever style recomputations are needed.

We'll need some APIs to let them do so, then, unless they want to pessimistically force a restyle of the whole subtree rooted at the changed element.

> Do we even modify these attributes on rendered elements?

Good question!

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #3)
> A custom, chrome-only, pseudo class should do it. It'd be really cool if we had
> a chrome-only pseudo class like:
> 
> :-moz-internal-property(foo)
> 
> which mapped to checking if nsINode::GetProperty mapped to
> NS_PROPTABLE_PROP_NOT_THERE.

Long ago, fo the reason outlined in this bug precisely, I suggested to
make a pseudo checking the value of a DOM userData attached to an element.
That would help getting rid of these classes.

Comment 8

[(no longer active)]

(In reply to comment #5)
> Do we even modify these attributes on rendered elements?

We might.

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.