Cannot change behaviour for actions from Options page, and if changed manually they don't persist
Closed this issue · 20 comments
0.0.2.9 on Chromium 22
Why is the default 'pass' anyway? There's no point blacklisting sites after they've tracked you.
I'm afraid you have to click the save button for now.
Labeling it as a bug to fix saving without having to click save.
The choice of 'pass' is to not interfere in the browsing traffic until the user is familiar with the tools. For new installs a small block list is included.
There's no save button for the default action dropdowns at the top, though.
The top ones are saved automatically at once.
I tried using 22.0.1201.0 dev but it works there for me.
Please describe a test case for a change that does not persist.
1- Open the Options page
2- Change 'Default action' to 'block'
3- Close Options
4- Open options, 'Default action' is back to 'pass'
Tried it, still works here, we need some more debugging.
Please open the inspection view of the extensions background page(from the extensions page check debug mode and click the "background.html" for the extension) and open the console(shift+ctrl+i, click the ">=" symbol if not open). Then report if any message appears there.
I can't reproduce the error so in my case the consoles are empty.
Nope, nothing there.
Then I'm afraid the fix is far away, will require a step by step debugging through the code.
A workaround for your case is though to open the "Resources" "tab" for the "background.html" page, expand Local storage and select the item there.
There you can edit the values by hand.
You will need to restart chromium or the extension for the changes to take effect.
They're not getting set on first run in settings.js.
They are called:
- defaultAction
- defaultLocalAction
- defaultNewFilterAction
Their values are only the codename of the action such as pass, clear or block.
Hope the previous workaround worked for you.
Since I cannot reproduce the bug an no errors are caused there are nothing more that can be done at this moment so I'm closing the issue.
I'm having the same issue: the settings for default actions aren't getting saved, and when I right click, go to "Inspect Element," and go to the Resources tab, the Local Storage is empty.
That's what happens on options.html, though at your suggestion I managed to get to background.html (I couldn't find it linked anywhere, so I did an "Inspect Element" on a link on options.html and edited where it went). background.html did have Local Storage, and I added the extra data like you suggested (and these values persist even when I reload the page). However, options.html still isn't picking them up (which makes sense, given that it isn't using any local storage).
I'm on a Mac (Snow Leopard) running Chrome 23.0.1271.64. I'm using KISS version 0.0.3.5.
What can I do to help diagnose the problem? Any idea how I can work around it? Thanks for your time.
I think I figured it out. in manifest.json, you needed to add the "background" permission:
"permissions": [ "background", "webRequest", "webRequestBlocking", "tabs", "\u003Call_urls\u003E" ],
With that added, things are working much better.
The background page can be found in Settings->Extension and then click on the background.html link at the Kiss extension.
And yes it is the local storage for the background page where all the settings reside.
From what I can tell the "background" permission is about running while the browser is closed which for this extension is not a requirement, these settings are put into the local storage immediately when another option is selected in the drop down so there should not be any delayed writing.
I'm running chrome 24 but this part of the code has been along since many versions before 23.
Debugging should be really straightforward in this case.
Inspect the options page and set breakpoints in options.js line 88 and forward for the following 3 methods:
function defaultActionClick()
{
b.setDefaultAction(this.value);
}
function defaultLocalActionClick()
{
b.setDefaultLocalAction(this.value);
}
function defaultNewFilterActionClick()
{
b.setDefaultNewFilterAction(this.value);
}
The b is the background page, this.value should be the value you selected.
When you cange a setting the breakpoint should be hit.
Now follow into the b.setDefault....
The first defaultAction, which is the default for cross domain requests looks like this:
function setDefaultAction(f){
defaultAction = f;
localStorage.defaultAction = f;
}
You can place a breakpoint here and in the 3 following functions in the same file.
The first line is keeping a local copy of the setting which will be used for the remainder of the chrome session,
the second line is the one saving the settings, while stepping past that one you should see the change being done in the local storage of the background page.
I uninstalled and reinstalled KISS, and verified that I couldn't save the settings any more. I used your trick of clicking on background.html in Settings > Extensions to verify that I had no default values set for defaultAction and the others. I opened up the KISS settings, put breakpoints on those three functions, hit the "pause" button in Chrome's debugger (so that it will pause on the next breakpoint), and played around with the default action choices. Nothing---Chrome didn't pause.
To check that I was using the debugger correctly, I added another breakpoint in ignoreWWWClick() (note that background.html comes with a default value for ignoreWWW). When I unchecked the "ignore leading www." option, Chrome paused at the breakpoint; the debugger was working fine. So, defaultActionClick() and the other two are not getting called when I change those settings.
At this point, I went back to background.html and added in values for defaultAction and the others, went back to options.html and reloaded the page. The new values were shown correctly. However, I was still unable to change them from within options.html itself, and the breakpoints were still not being executed. So, the problem isn't contingent on values already being set in background.html.
I got the idea of the background permission from [1], but I am now unable to reproduce my fix. Despite my adding that permission into manifest.json again (and disabling and re-enabling KISS and hitting the "Update extensions now" button), I still can't save from the settings page, and those breakpoints still don't get tripped. Note that in contrast to [1], KISS can get the background file, since I can modify ignoreWWW in it.
I can use your workaround of editing stuff directly in background.html, and that's good enough for me. Thanks for the tip!
[1] http://stackoverflow.com/questions/7971566/chrome-extension-getbackgroundpage-returns-null-why
It sounds like the code for saving the settings are not called at all.
Currently it only listens for click event, perhaps mac is not triggering those.
I changed it to a "change" event instead, works for both clicks and keyboard navigation. Will be up soon.
Yup, it works great now. Thanks for the fix!
Thanks for this update, but I can't change the presets for the actions still, i.e., I can change filter matching, default action, new filters and always pass same, but not the detailed action presets.
Cheers
sani please try the debug steps I described right before I reopened this issue above and let me know the outcome, especially where those settings that work and don't differ.
I've added a breakpoint on line 269. Changing the colour would trigger a break, but changing any of the other options would not. You're using the onclick method to change the rest of them (lines 294 to 301), which is why it's not working, I guess.
That's done it; thank you.