Closed Bug 978251 Opened 11 years ago Closed 11 years ago

"target is null" when clicking on contents of panel

Categories

(Firefox :: Extension Compatibility, defect)

defect
Not set
normal

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+
Whiteboard: [Australis:P3-][fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Closed: 11 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.

Attachment

General

Created:
Updated:
Size: