Open
Bug 531159
Opened 15 years ago
Updated 3 years ago
No documentation on _moz_resizing/_moz_abspos or how to disable it
Categories
(Core :: DOM: Editor, defect, P5)
Tracking
()
UNCONFIRMED
People
(Reporter: electronic, Unassigned)
Details
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•14 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•13 years ago
|
Component: DOM → Editor
QA Contact: general → editor
Comment 2•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
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?
Comment 6•13 years ago
|
||
> 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.
Comment 8•13 years ago
|
||
(In reply to comment #5) > Do we even modify these attributes on rendered elements? We might.
Comment 9•3 years ago
|
||
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.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•