Closed Bug 540843 Opened 12 years ago Closed 12 years ago

Do not cache dom element in nsObjectFrame shm code

Categories

(Core :: Plug-ins, defect)

All
Maemo
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .1+
status1.9.2 --- .1-fixed
fennec 1.0+ ---

People

(Reporter: dougt, Assigned: dougt)

References

Details

Attachments

(1 file)

No description provided.
Attached patch patch v.1Splinter Review
Assignee: nobody → mozbugz
Attachment #422545 - Flags: review?(jst)
blocking1.9.2: --- → ?
tracking-fennec: --- → ?
tracking-fennec: ? → 1.0+
Having the nsObjectFrame own a content dom element is bad practice.  We do not need to do that because we can cache the X window instead.  This is basically what we were already doing inside of SetupXShm.

The drawback is that once chrome calls SetAbsolutePosition, it can not change its mind with respect to what element the object element content is parented to.  This is find, because that case was never suppose to work.  (we had a runtime test to prevent that from happening).
Attachment #422545 - Flags: review?(jst) → review+
http://hg.mozilla.org/mozilla-central/rev/4539d8e6411e
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d2a5c5f46038
Status: NEW → RESOLVED
blocking1.9.2: ? → ---
Closed: 12 years ago
Resolution: --- → FIXED
Blocks: 539775
You need to log in before you can comment on or make changes to this bug.