Closed Bug 93500 Opened 23 years ago Closed 23 years ago

Coordinates for NPWindow messed up for Windowless plugins

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: kevint, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: [a=chofmann])

Attachments

(1 file)

patch to use signed x,y coords v.1
1.17 KB, patch
Details | Diff | Splinter Review 
For windowless plugins, the 'y' coordinate of the NPWindow passed into 
NPP_SetWindow() is incorrect; in my tests it was giving me something in the 
million or billion range.  Tracing it back to nsObjectFrame::DidReflow(), it 
calls parentFrame->GetOffsetFromView(), which is where it seems to get the 
wrong coordinate from.

*** This bug has been marked as a duplicate of 93056 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I discovered that this is actually not a duplicate of 93506, but the problem 
boils down to the fact that the 'x' and 'y' parameters of NPWindow in npapi.h 
were changed from int32 to uint32 - so if the y coordinate of a windowless 
embed is negative, it'll come in as 0xFFFFFFFE, for example. I think using 
int32 here is probably appropriate.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Andrei, what do you think about the change?
Status: UNCONFIRMED → NEW
Ever confirmed: true
We should get it back, I think.
Reassign to myself. Seeking reviews.
Assignee: av → peterlubczynski
Keywords: patch, topembed
Priority: -- → P3
Whiteboard: [seeking reviews]
Target Milestone: --- → mozilla0.9.4
r=av
sr=attinasi
Patch in trunk. Seeking '+' for branch.
Status: NEW → ASSIGNED
Keywords: review
Whiteboard: [seeking reviews] → [patch in trunk][seeking approval]
a=chofmann for the 0.9.2 branch.  thanks
Whiteboard: [patch in trunk][seeking approval] → [patch in trunk][a=chofmann]
Patch in branch, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
verif that patch went in trunk as version 3.13
Whiteboard: [patch in trunk][a=chofmann] → [verif in trunk][a=chofmann]
verif patch in trnk. marking as such
Status: RESOLVED → VERIFIED
Whiteboard: [verif in trunk][a=chofmann] → [a=chofmann]
meant branch...
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: