Closed Bug 899447 Opened 11 years ago Closed 11 years ago

Color picker in FoxyProxy extension is broken

Categories

(Core :: JavaScript Engine, defect)

24 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla25
Tracking Status
firefox23 --- unaffected
firefox24 + verified
firefox25 + verified

People

(Reporter: gk, Assigned: bhackett1024)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)

Steps to reproduce:

I installed FoxyProxy Standard (4.2.1) in a clean, new profile. After a restart I clicked on the FoxyProxy icon in the toolbar and then I double-clicked on the default proxy in the proxy tree. Clicking on the color picker in the "Icon color when proxy is in use"-row shows the FoxyProxy color picker.


Actual results:

No colors are shown and the color can't be changed. Moreover, the error console shows:
ReferenceError: color2 is not defined colorpicker2.xml:280


Expected results:

The colors should show up and the proxy color should be selectable.
OS: Windows 7 → All
Hardware: x86 → All
Seems to be caused by bug 678037.
Blocks: LazyBytecode
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: regression
Reg cChangelog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b197bed90a98&tochange=3d16d59c9317
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bhackett1024)
bhacktett, is the user impact limited to Foxy Proxy or are is this a generic issue and can impact things outside of it as well ?
WFM on tip.  Georg, what branch are you testing on?  Your user agent predates when bug 678037 landed.
Flags: needinfo?(bhackett1024)
I used latest nightly. And I bisected the issue using mozilla-central.
Attached patch patch β€” β€” Splinter Review
OK, thanks.  I tried with a nightly and was able to reproduce it, then tried again with my local build.  For some reason this doesn't repro with a --enable-debug browser.

The problem is an interaction of lazy parsing with incorrect information set about the script when it was compiled.  We use a flag during compilation to specify scripts that can only run against global objects, and this flag was being set even for scripts in an XML document that can run against a XUL element.  This caused lazily parsed scripts to be compiled incorrectly.  The attached patch should fix this bug.
Assignee: general → bhackett1024
Attachment #784502 - Flags: review?(luke)
Attachment #784502 - Flags: review?(luke) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/e6f86230157d
https://hg.mozilla.org/mozilla-central/rev/e6f86230157d
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Comment on attachment 784502 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): old, but exposed by 678037
User impact if declined: broken extensions
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): little, may need a few days of bake time
Attachment #784502 - Flags: approval-mozilla-aurora?
(In reply to Brian Hackett (:bhackett) from comment #6)
> For some reason this doesn't repro with a --enable-debug browser.

Because of this, could a test be written for this please?
(setting needinfo for comment 10, because I really should learn to do that and this is FIXED)

I'm just a passer-by here but an opt-only extension-only bug screams "automatic test" to me. ;)
Flags: needinfo?(bhackett1024)
If someone wants to write a test for this that would be great, but this would need a mochitest or something that I don't know how to write, and since this is an old bug that was only tickled by a patch I wrote I don't feel obligated to write the test myself.
Flags: needinfo?(bhackett1024)
Attachment #784502 - Flags: approval-mozilla-beta+
Attachment #784502 - Flags: approval-mozilla-aurora?
Attachment #784502 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-beta/rev/9191dd96f6b0
evilpie and I both tend to think that we should be writing tests for self-introduced temporary bugs, just as much as we write tests for any other sort of bug.  It should be pretty trivial to write a jsapi-test for this, I think.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0

Verified as fixed on Firefox 24 beta 10 (buildID: 20130909203154) and latest Nightly (buildID: 20130909030204).
Keywords: verifyme
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0

Also verified as fixed on latest Aurora 25.0a2 (buildID: 20130910004002).
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: