Closed Bug 978251 Opened 6 years ago Closed 6 years ago

"target is null" when clicking on contents of panel

Categories

(Firefox :: Extension Compatibility, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 30
Tracking Status
firefox29 --- fixed
firefox30 --- fixed

People

(Reporter: jorgev, Assigned: Gijs)

References

Details

(Whiteboard: [Australis:P3-][good first verify])

Attachments

(2 files)

Attached file aus-view.xpi
I'm writing some demos for CustomizableUI and ran into this problem.

STR:
1) Install add-on in the attachment.
2) Click on the smiley face. You should see a panel with a select box and button.
3) Click anywhere in the panel. You should see this error in the Browser Console, once per click:

target is null CustomizableUI.jsm:1277

I haven't checked, but it could be that the error only happens because the panel has an internal iframe. While this doesn't appear to break anything, we generally don't allow AMO add-ons to generate errors in the Console.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Jorge Villalobos [:jorgev] from comment #0)
> I haven't checked, but it could be that the error only happens because the
> panel has an internal iframe. While this doesn't appear to break anything,
> we generally don't allow AMO add-ons to generate errors in the Console.

Yup. But we can just fix this...
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(gijskruitbosch+bugs)
Writing a test for this is sadly tricky because error messages, though... in any case, the fix is so low-impact that I think we should just land this.
Attachment #8384110 - Flags: review?(jaws)
Comment on attachment 8384110 [details] [diff] [review]
nullcheck target in Australis' panel click detection code,

Review of attachment 8384110 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/customizableui/src/CustomizableUI.jsm
@@ +1270,5 @@
>  
>      // While keeping track of that, we go from the original target back up,
>      // to the panel if we have to. We bail as soon as we find an input,
>      // a toolbarbutton/item, or the panel:
> +    while (true && target) {

Yes, we should have done this from the beginning.
Attachment #8384110 - Flags: review?(jaws) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/00d0a9b4b0d4
Whiteboard: [Australis:P3-][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/00d0a9b4b0d4
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3-][fixed-in-fx-team] → [Australis:P3-]
Target Milestone: --- → Firefox 30
Comment on attachment 8384110 [details] [diff] [review]
nullcheck target in Australis' panel click detection code,

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis
User impact if declined: add-ons cause spurious exceptions, don't get correct close handling
Testing completed (on m-c, etc.): on m-c, locally
Risk to taking this patch (and alternatives if risky): none, simple null-check
String or IDL/UUID changes made by this patch: none
Attachment #8384110 - Flags: approval-mozilla-aurora?
Attachment #8384110 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [Australis:P3-] → [Australis:P3-][good first verify]
You need to log in before you can comment on or make changes to this bug.