No documentation on _moz_resizing/_moz_abspos or how to disable it

UNCONFIRMED
Unassigned

Status

()

Core
Editor
UNCONFIRMED
8 years ago
4 years ago

People

(Reporter: electronic Max, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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

7 years ago
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.

Updated

6 years ago
Component: DOM → Editor
QA Contact: general → editor
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?
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.
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.
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?
> 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!
(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.
(In reply to comment #5)
> Do we even modify these attributes on rendered elements?

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