Any news on the purportedly reproduceable bug with the 0.62 version and custom attention services? I'm eagerly waiting to do some work on the toolkit and the fact that I can't record to it makes a too-convenient excuse...
Cori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it has been determined that its not a problem with custom services. Its actually a worse bug -- in FF 1.5 with ATX .62, it works if and only if you have precisely one attention service configured.
please try reducing the attentionBank list to only your custom service, and see if it works.
thanks,
mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I figured it was something that changed in FF1.5, but was hoping that it was more along the lines of a changed feature that needed some adjustment in ATX than a bug per se.
I beg to differ with the single-source assessment, however. Unless LOCAL doesn't count as one than that's not the case becuase I could use Root.net and LOCAL just fine. Even if that is the case, when I remove Root.net and LOCAL and add my custom service in about:config, ATX stops recording (at least that's my experience, reinforced this morning).
If this is an FF1.5 bug that you aren't planning on doing more work on for now then I suspect I'll downgrade to a previous version (bummer).
Thanks!
cori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This bug is elusive, probably because there has been little if any real debugging time put into finding it.
I can say this conclusively. Running Firefox 1.5, and the newest available version of the ATX in this past week worked for me, with a custom service URL. I did need to restart firefox after setting about:config for it to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the newest version newer than 0.62? I'll try again; I'd dearly love to be able to keep my upgrade, and I'd also like to start deploying more extensions (which I've avoided thus far to keep from obscuring the ATX problems).
Out of curiosity, were you able to run the custom extension with another one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if you're willing to downgrade FF, the ATX should work fine with other extensions. I have the ATX with 3 services (2 custom) and a bunch of extensions, and it all works fine.
-mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frustratingly, I had it working briefly over the holiday, with FF 1.5. Then it stopped.
I'm curious, Mike, do you have any exclusions set up? I have since downgraded and got it working again, then it stopped again, suspiciously enough right after I added an exclusion. I have it running right now under another new profile and after I confirm that it keeps working for a while will add an exclusion and see if it stops, but would be interested to know if you have exclusions running.
Thanks!
cori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm now running FF1.0.7 and ATX 0.62, and I;ve located what might be the bug that's been causing me all this heartache. At the very least it's a bug, I think, and one with broader repercussions regarding custom services.
Here are the symptoms I've found in my environment:
* any time you ave a custom service enabled added and you use the AttentionRecorder options dialog and click the OK button, ATX will delete your custom service adddress(es). If you click the cancel button nothing will change, and if you (for example) add items to your exclusions list via right-click everything will be OK.
Here's where I think the problem is:
* in attentionOptions.js, starting on line 124, ATX goes about setting the Firefox attention.attentionbankSendList pref.
* It goes to get a banksList array based, I think, on approved members (the attention.attentionBanksList pref).
* It checks those to see if any are checked, and if they are, adds them to a sendlist variable.
* It checks to see if LOCAL is checked, and if so adds it to sendlist.
* it sets attention.attentionbankSendList = sendlist.
Notice that nowhere in there does ATX look to see if there's something already in attention.attentionbankSendList before overwriting it with the new values.
I'm posting a patch to attentionOptions.js that:
* pre-seeds sednBank with the contents of attention.attentionbankSendList
* for each bankURL that's checked, checks to make sure that the url's not already in sendList. If it's not it adds it, if it is it doesn't.
* does the same with "LOCAL"
This is probably not a secure solution to the problem, but it's better (for me at least) than none.
FWIW, I think the right solution is to have a Custom Service field in the options dialog that controls the attention.attentionbankSendList contents along with the other options. I don't have enough XUL yet to make this change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't do the debugging myself so I can't really speak to what you found, but a new version of the ATX has been posted on attentiontrust.org. if you update your extensions in FF, it should automatically get the new version.
give it a shot.
-mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Mike;
I saw the update and retrieved it (of course, almost immediately after posting my comments and my patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1402043&group_id=154773&atid=793138)).
As I noted in the follow-up in the patch, the new version still has this bug, and the patch still fixes it.
thanks
cori
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm. Dunno. I was pretty sure I uploaded it, but perhaps I forgot a step.
Given arantius's response (https://sourceforge.net/forum/message.php?msg_id=3515975), maybe it's irrelevant. However, if you still want the patch I'll repost later when I'm back on the machine that has the file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> any time you ave a custom service enabled added
> and you use the AttentionRecorder options dialog
> and click the OK button, ATX will delete your
> custom service adddress(es).
This is not a bug, this is intentional behavior. You may argue whether this is a good or bad behavior, but this is the way it was built to work.
(Personal not official statement follows.)
There's two issues at work here. First, if you're configuring a custom service, the assumption is that this is a temporary thing, that you are a developer making what is to be a new Attention Trust certified service, and soon you will be in the options dialog, so only basic functionality is provided.
Second, the Attention Trust certifies services for a reason. When you use that options window, you are selecting which *approved services* to transmit your data to. This window knows nothing of custom services, or in fact any service besides local storage and those that are Attention Trust approved.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wish you'd been around a few days ago when I started wrestling with this - would have saved me some headaches.
I *would* argue it, at least to a degree. Philosophcally I don't think it's the right thing to do - I think there are other, less drastic ways to protect users, which I gather is the intent. That's probably a discussion for a different forum, though.
Even if I agreed with the philosophy, though, architecturally I think it's less than ideal. There's no communication with the user, who has no idea that something they didn't explicitly choose to alter is being changed. Even if you take control of this away from the user entirely they at least deserve to know what's being done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree, Mike. In fact I'm hoping to do some development on the Attention Toolkit, and the one thing that was stopping me was not being able to record my attention data to it reliably. It was serious enough to cause me to downgrade to FF1.07, perhaps needlessly.
I hope the development team will reconsider this decision.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey gentlemen;
Any news on the purportedly reproduceable bug with the 0.62 version and custom attention services? I'm eagerly waiting to do some work on the toolkit and the fact that I can't record to it makes a too-convenient excuse...
Cori
Cori,
it has been determined that its not a problem with custom services. Its actually a worse bug -- in FF 1.5 with ATX .62, it works if and only if you have precisely one attention service configured.
please try reducing the attentionBank list to only your custom service, and see if it works.
thanks,
mike
Mike-
I figured it was something that changed in FF1.5, but was hoping that it was more along the lines of a changed feature that needed some adjustment in ATX than a bug per se.
I beg to differ with the single-source assessment, however. Unless LOCAL doesn't count as one than that's not the case becuase I could use Root.net and LOCAL just fine. Even if that is the case, when I remove Root.net and LOCAL and add my custom service in about:config, ATX stops recording (at least that's my experience, reinforced this morning).
If this is an FF1.5 bug that you aren't planning on doing more work on for now then I suspect I'll downgrade to a previous version (bummer).
Thanks!
cori
i will forward this to the person who made that assesment. the bug is on the list of things to fix, but might not be addressed for a number of weeks.
in the meantime, mabye its best to downgrade your FF for a bit...
thanks for the patience,
mike
This bug is elusive, probably because there has been little if any real debugging time put into finding it.
I can say this conclusively. Running Firefox 1.5, and the newest available version of the ATX in this past week worked for me, with a custom service URL. I did need to restart firefox after setting about:config for it to work.
Is the newest version newer than 0.62? I'll try again; I'd dearly love to be able to keep my upgrade, and I'd also like to start deploying more extensions (which I've avoided thus far to keep from obscuring the ATX problems).
Out of curiosity, were you able to run the custom extension with another one?
0.62 is the most recent version.
if you're willing to downgrade FF, the ATX should work fine with other extensions. I have the ATX with 3 services (2 custom) and a bunch of extensions, and it all works fine.
-mike
OK, that's what I thought.
Frustratingly, I had it working briefly over the holiday, with FF 1.5. Then it stopped.
I'm curious, Mike, do you have any exclusions set up? I have since downgraded and got it working again, then it stopped again, suspiciously enough right after I added an exclusion. I have it running right now under another new profile and after I confirm that it keeps working for a while will add an exclusion and see if it stops, but would be interested to know if you have exclusions running.
Thanks!
cori
i have used exclusions successfully.
-mike
I'm now running FF1.0.7 and ATX 0.62, and I;ve located what might be the bug that's been causing me all this heartache. At the very least it's a bug, I think, and one with broader repercussions regarding custom services.
Here are the symptoms I've found in my environment:
* any time you ave a custom service enabled added and you use the AttentionRecorder options dialog and click the OK button, ATX will delete your custom service adddress(es). If you click the cancel button nothing will change, and if you (for example) add items to your exclusions list via right-click everything will be OK.
Here's where I think the problem is:
* in attentionOptions.js, starting on line 124, ATX goes about setting the Firefox attention.attentionbankSendList pref.
* It goes to get a banksList array based, I think, on approved members (the attention.attentionBanksList pref).
* It checks those to see if any are checked, and if they are, adds them to a sendlist variable.
* It checks to see if LOCAL is checked, and if so adds it to sendlist.
* it sets attention.attentionbankSendList = sendlist.
Notice that nowhere in there does ATX look to see if there's something already in attention.attentionbankSendList before overwriting it with the new values.
I'm posting a patch to attentionOptions.js that:
* pre-seeds sednBank with the contents of attention.attentionbankSendList
* for each bankURL that's checked, checks to make sure that the url's not already in sendList. If it's not it adds it, if it is it doesn't.
* does the same with "LOCAL"
This is probably not a secure solution to the problem, but it's better (for me at least) than none.
FWIW, I think the right solution is to have a Custom Service field in the options dialog that controls the attention.attentionbankSendList contents along with the other options. I don't have enough XUL yet to make this change.
I wish there was a preview. or at least an "edit".
hmpf.
I didn't do the debugging myself so I can't really speak to what you found, but a new version of the ATX has been posted on attentiontrust.org. if you update your extensions in FF, it should automatically get the new version.
give it a shot.
-mike
Hey Mike;
I saw the update and retrieved it (of course, almost immediately after posting my comments and my patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1402043&group_id=154773&atid=793138)).
As I noted in the follow-up in the patch, the new version still has this bug, and the patch still fixes it.
thanks
cori
aha, cool. but maybe I'm an idiot -- where is the patch file?
thanks,
mike
Hmm. Dunno. I was pretty sure I uploaded it, but perhaps I forgot a step.
Given arantius's response (https://sourceforge.net/forum/message.php?msg_id=3515975), maybe it's irrelevant. However, if you still want the patch I'll repost later when I'm back on the machine that has the file.
I forgot to check the upload checkbox, I think. In any case it's there now.
> any time you ave a custom service enabled added
> and you use the AttentionRecorder options dialog
> and click the OK button, ATX will delete your
> custom service adddress(es).
This is not a bug, this is intentional behavior. You may argue whether this is a good or bad behavior, but this is the way it was built to work.
(Personal not official statement follows.)
There's two issues at work here. First, if you're configuring a custom service, the assumption is that this is a temporary thing, that you are a developer making what is to be a new Attention Trust certified service, and soon you will be in the options dialog, so only basic functionality is provided.
Second, the Attention Trust certifies services for a reason. When you use that options window, you are selecting which *approved services* to transmit your data to. This window knows nothing of custom services, or in fact any service besides local storage and those that are Attention Trust approved.
arantius;
Wish you'd been around a few days ago when I started wrestling with this - would have saved me some headaches.
I *would* argue it, at least to a degree. Philosophcally I don't think it's the right thing to do - I think there are other, less drastic ways to protect users, which I gather is the intent. That's probably a discussion for a different forum, though.
Even if I agreed with the philosophy, though, architecturally I think it's less than ideal. There's no communication with the user, who has no idea that something they didn't explicitly choose to alter is being changed. Even if you take control of this away from the user entirely they at least deserve to know what's being done.
I sorta feel the same way. remember, we're trying to _encourage_ developers to build their own attention services.
I agree, Mike. In fact I'm hoping to do some development on the Attention Toolkit, and the one thing that was stopping me was not being able to record my attention data to it reliably. It was serious enough to cause me to downgrade to FF1.07, perhaps needlessly.
I hope the development team will reconsider this decision.
Bug is confirmed with AttentionRecorder 0.63 and Firefox 1.0.7.
I agree with what Cori says on having a field in the Options dialog for custom services.
Best regards,
Lars Brenna