Closed Bug 586938 Opened 9 years ago Closed 9 years ago

missing VIEWPORT enum in WebGL context

Categories

(Core :: Canvas: WebGL, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: opensource, Assigned: vlad)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3

WebGL's VIEWPORT enum is not implemented, resulting in an OpenGL 'Invalid Enum' error.

Reproducible: Always

Steps to Reproduce:
1. Where gl represents a WebGL context:
2. Execute javascript: var arrViewport = gl.getParameter(gl.VIEWPORT);
Actual Results:  
Javascript exception is thrown and WebGL throws and gl.getError() returns gl.INVALID_ENUM.

Expected Results:  
arrViewport represents a four-element Int32 array.

Request was made from an extension dialog.
Component: General → Canvas: WebGL
Product: Firefox → Core
QA Contact: general → canvas.webgl
Version: unspecified → Trunk
yes, we know about this problem.

The real problem is that there already is a function, gl.viewport(). And we have trouble with identifiers that only differ by case. But Vlad's working on this.
Assignee: nobody → vladimir
Yep, it's currently VIEWPORT_RECT, but at some point this will be fixed.  In the meantime you could use the actual hex value (0x0BA2) and get the same behaviour on all browsers.. ugly, but would work.
Status: UNCONFIRMED → NEW
blocking2.0: --- → final+
Ever confirmed: true
Summary: WebGL VIEWPORT preference enum not implemented → missing VIEWPORT enum in WebGL context
Vlad, do we have any chance of actually fixing this in a world involving xpidl?
Attached patch finallySplinter Review
Ended up being a lot simpler than I feared.  Thanks to mrbkap for the pointers!
Attachment #498897 - Flags: review?(mrbkap)
Comment on attachment 498897 [details] [diff] [review]
finally

It would be better to detect failure from JS_DefineProperty and return NS_ERROR_FAILURE or something similar in that case. Looks good otherwise.
Attachment #498897 - Flags: review?(mrbkap) → review+
http://hg.mozilla.org/mozilla-central/rev/3a72f8d24d43 finally.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.