Closed Bug 116108 Opened 24 years ago Closed 24 years ago

[viewpoint] Windowless plugin does not preserve its position if in a table cell

Categories

(Core Graveyard :: Plug-ins, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: serhunt, Assigned: serhunt)

Details

Attachments

(2 files, 1 obsolete file)

This bug is off-spring from bug 114667. If you use <table><tr><td><embed ...><\td><\tr><\table> construction with the windowless plugin, you will see that the plugin is not drawn in the table. With the fix from bug 116093 it is drawn correctly but if the table position changes the plugin does not follow. Test case to follow, please install ViewPoint plugin for testing purposes: http://cole.viewpoint.com/~aberger/viewpointplugin.zip -- run .exe from this package, it will install the engine, then copy the plugin dll into the Plugins folder and xpt file in the Components folder. You may use newer than in the package dll and xpt: http://cole.viewpoint.com/~aberger/npViewpoint.zip http://cole.viewpoint.com/~aberger/npViewpoint.xpt
...restoring original nominations.
Severity: normal → critical
Status: NEW → ASSIGNED
Keywords: edt0.9.4
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Run this test case and resize the window to see the problem. The table is <center>'ed and moves, the plugin does not.
Attached patch patch v.1 (obsolete) — Splinter Review
This patch assumes that the patch v.2 from bug 116093 is already applied. With both patches all test cases now work fine. Issue with dirty rectangle is still to be addressed. Please review and try.
This patch works for me and it also fixes 110094.
One problem with the patch is that in the case where DidReflow is called correctly then all the stuff to recalculate the origin is done twice which is a bit of a waste. Is it worth putting a note in the code that a better way should be found of fixing this in the future? Ie. figuring out why DidReflow isn't being called when the plugin is in a table.
Twice, you mean in DidReflow and Paint? Tables are not reflown by design, unless the size is changed. This was a performance consideration, I beleive.
Summary: Windowless plugin does not preserve its position if in a table cell → [viewpoint] Windowless plugin does not preserve its position if in a table cell
Attached patch patch v.2Splinter Review
This patch is just to reflect changes in bug 116093, so this patch will work with patch v.4 from bug 116093.
Attachment #62296 - Attachment is obsolete: true
Keywords: patch
Comment on attachment 62422 [details] [diff] [review] patch v.2 r=peterl
Attachment #62422 - Flags: review+
Andrei, I did mean in Paint and DidRfelow. Your patch in bug 116093 that moves everything into the Paint method seems a good solution and avoids this happening.
Keywords: edt0.9.4edt0.9.4+
Comment on attachment 62422 [details] [diff] [review] patch v.2 sr=attinasi
Attachment #62422 - Flags: superreview+
In the trunk. Nominating for 0.9.7.
Keywords: patchmozilla0.9.7
In 0.9.4, marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Keywords: mozilla0.9.7
Target Milestone: mozilla0.9.7 → ---
Confirmed fixed on mozilla trunk 122603(viewpoint plugin stays inside table and does not move out). Ari, could you please confirm the fix as well. Thanks! I have filed http://bugscape.mcom.com/show_bug.cgi?id=11566 for a problem that I see using commercial trunk builds. Cannot verify the fix on the embedding branch unless I get thru that problem.
Keywords: fixed0.9.4
testcase works, plugin draws inside table when loaded. used build 0101 0.9.4 branch. VERIF.
Status: RESOLVED → VERIFIED
Just noticed what Ari mentioned in one of his email('I have also seen a problem with our content drawing incorrectly when you scroll the page. Again, I don't know where the problem lies') When I resized the test page and tried to scroll...there was a problem rendering the content in the plugin and scrollbar got locked. Ari, pls file a bug if you think this is a mozilla problem.Thanks!
I have been working on another (higher priority) bug. I will look into this in the next few days. What is the preference? Would you rather I log the issue when it may well be our bug, or wait until I am reasonably sure it is Mozilla's? Thanks.
Ari, I filed bug 117793 for the issue that you mentioned and what I saw here. Pls add your comments to it whenever you get time. Thanks!
adding keyword 'verified0.9.4'
Keywords: verified0.9.4
Keywords: fixed0.9.4
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: