Closed Bug 540843 Opened 15 years ago Closed 15 years ago

Do not cache dom element in nsObjectFrame shm code

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
All
Maemo
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking1.9.2 .1+, status1.9.2 .1-fixed, fennec1.0+)

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

People

(Reporter: dougt, Assigned: dougt)

References

Details

Attachments

(1 file)

patch v.1
3.67 KB, patch
smaug
: review+
Details | Diff | Splinter Review
No description provided.
Attached patch patch v.1 — — Splinter 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: 15 years ago
status1.9.2: --- → final-fixed
Resolution: --- → FIXED
Blocks: 539775
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: