Blackboxing a program in the shader editor should, in fact, hide the rendered geometry, not create black holes

RESOLVED FIXED in Firefox 27

Status

defect
P2
normal
RESOLVED FIXED
6 years ago
4 months ago

People

(Reporter: vporof, Assigned: vporof)

Tracking

unspecified
Firefox 28
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox26 unaffected, firefox27 fixed, firefox28 fixed)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment, 1 obsolete attachment)

Right now it replaces it with (supposedly) transparent black.

However, depending on the webgl context state, especially when alpha blending is disabled, it won't work, drawing it as opaque black. This is ANNOYING.
Posted patch webgl-blackbox.patch (obsolete) — Splinter Review
Would like to land this on aurora before the Hacks blog post on 11th.
Assignee: nobody → vporof
Status: NEW → ASSIGNED
Attachment #825764 - Flags: review?(dcamp)
Priority: -- → P2
Depends on: 930928
Blocks: 933649
Summary: Blacboxing a program in the shader editor should, in fact, hide the rendered geometry, not create black holes → Blackboxing a program in the shader editor should, in fact, hide the rendered geometry, not create black holes
Attachment #825764 - Flags: review?(dcamp) → review?(rcampbell)
Attachment #825764 - Flags: review?(rcampbell) → review+
Rebased to land this first.
Attachment #825764 - Attachment is obsolete: true
Attachment #826962 - Flags: review+
(In reply to Wes Kocher (:KWierso) from comment #4)
> Backed out in https://hg.mozilla.org/integration/fx-team/rev/eb06bfe7f9b6
> for breaking xpcshell tests like this
> https://tbpl.mozilla.org/php/getParsedLog.php?id=30097045&tree=Fx-Team

Damn strict warnings !!
Comment on attachment 826962 [details] [diff] [review]
webgl-blackbox.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): New feature!
User impact if declined: Some minor-ish functionality for the Shader Editor will be confusing or useless.
Testing completed (on m-c, etc.): locally, fx-team
Risk to taking this patch (and alternatives if risky): None
String or IDL/UUID changes made by this patch: None
Attachment #826962 - Flags: approval-mozilla-aurora?
(In reply to Victor Porof [:vp] from comment #6)
> https://hg.mozilla.org/integration/fx-team/rev/64e809f87e60

Can you confirm what versions of firefox versions are affected here by setting the status flags. Unclear from the blocking bug.
https://hg.mozilla.org/mozilla-central/rev/64e809f87e60
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 28
(In reply to bhavana bajaj [:bajaj] from comment #8)
> (In reply to Victor Porof [:vp] from comment #6)
> > https://hg.mozilla.org/integration/fx-team/rev/64e809f87e60
> 
> Can you confirm what versions of firefox versions are affected here by
> setting the status flags. Unclear from the blocking bug.

Bug 930928 also has an aurora approval request.
Attachment #826962 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: verifyme
I see that this bug has in-testsuite+. Is there any help needed for manual testing here? If yes can you please provide some steps in order to reproduce and verify that this is fixed?
Flags: needinfo?(vporof)
There are automated tests for this.
Flags: needinfo?(vporof)
Keywords: verifyme
Based on comment 12: deleting verifyme keyword.
Whiteboard: [qa-]
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.