Loading Profile...
Disabling a command has no effect
- Sign up for a command using the 0.18 API
- Find that command feed in the command list, it says "Old API" next to it
- Uncheck the box beside it to disable the command
- There is no save button, so I assume changes take place immediately
- Restart browser, still get the "Old API commands" warning
- Check command list again, the uncheck had no effect and box is still checked
I'm using 0.5pre4.
- Find that command feed in the command list, it says "Old API" next to it
- Uncheck the box beside it to disable the command
- There is no save button, so I assume changes take place immediately
- Restart browser, still get the "Old API commands" warning
- Check command list again, the uncheck had no effect and box is still checked
I'm using 0.5pre4.
8
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The company marked this problem solved.
The best solution from the company
-
This is fixed in Ubiquity 0.5.4, which was released today.
The company and 1 other person say
this solves the problem
-
-
-
Inappropriate?Thanks for the report - I just added it to our bug tracker: http://ubiquity.mozilla.com/trac/tick... -
Inappropriate?Also, is your version the final 0.5?1 Comment Add a comment
This solves the problem
-
In 0.5 final, the checking/unchecking of a command in the command list does persist across window closes and restarts, so it looks like it's taking effect. Also the "enable command X" does also toggle the command's availability.
However, this doesn't get rid of the "some commands invalid with Parser 2" message as I expected it would. But it sounds like that's a different problem that's not just enabling disabling a command, you probably have to totally unsubscribe. -
Inappropriate?I have just upgraded to 0.5 final and the problem still persists.
-
1 Comment Add a comment
This solves the problem
-
Can you see if there's anything on your error console? (Tools -> Error console)
-
Inappropriate?Error: commandSource.getCommand(id) is null
Source File: chrome://ubiquity/content/cmdlist.js
Line: 314 -
Inappropriate?has there been any fix for this ?
it has just reverted in 0.5.3 after seemingly being fixed in 0.5.2 -
Inappropriate?theaulddubliner, there were no substantive changes between 0.5.2 and 0.5.3, so I find that unlikely.
We haven't been able to reproduce this behavior and have been scratching our heads—a number of us core developers are able to disable commands fine. You're welcome to test with our latest 0.5.4 prerelease:
http://ubiquity.mozilla.com/xpi/0.5.4...
Please also let us know what version of Firefox you're using.
I’m confused
-
Inappropriate?I have the same issue: I disable some commands I don't use, then if I try to run one of them in ubiquity, I can't, but if I close the command page and then reopen it, those commands are checked, so they should be enabled, try to run them in ubiquity has the same result of before.
Using 0.5.4pre2 with FF 3.5.2 on linux
I’m confident
1 Comment Add a comment
This solves the problem
-
Ah, t3ddy, thanks for your explanation! Now I see what you mean—you reload the command list and it is marked as enabled again!
We will look into this now. :) -
Inappropriate?This is fixed in Ubiquity 0.5.4, which was released today.
The company and 1 other person say
this solves the problem
1 Comment Add a comment
This solves the problem
-
Yes, now it works fine :)
-
Inappropriate?However unlikely I can attest that at the very least the checkboxes for commands would not remain unchecked on refresh.
They do now in 0.5.4.
I can not confirm if the problem was merely cosmetic [ie the checkboxes behaved incorrectly even if the command was disabled] - on upgrading to 0.5.4 it appears to have remembered deselections I made in the pre0.5.4 version even if they didn't show previously.
Seems 'fixed' now anyway.
I’m happy
EMPLOYEE
