Re: @decembre:

Never say never. ;) :) Eventually that feature will be on dev and trickle down... until then... one should think thoroughly before tapping the reply button. :) This also needs to be focused on GH issue tracker. Thanks.

Re: @decembre:

#461

Patience... the button/link is going away but with any luck a replacement will be ready hopefully in a few weeks or perhaps less... and I know you know this already. :P :)

This should be the end of the discussion here as it needs to be done on development under a GH issue to keep things focused. Thanks.

Nice addition.

Re: @devnoname120:

Because your account isn't the same here on OUJS as GH this won't auto-sync because you don't own the script under this username.

You will need to manually upload or paste your changes in if you keep it under your @devnoname120 to change the content stored here on OUJS... client/user side GM, or other, will pull from @HandyScripts on GH... however the OUJS source will not because that's not your account here on OUJS.

Seems that your external script host requires validation through google and we're not privy to that... this is the ultimate obfuscation and isn't permitted. Your script will be removed along with your account.

This site is for valid open-source projects not hidden. Bye

Does anyone realize that google has identified this script as potentially harmful and is occasionally preventing loading from it's referenced external source right? The obfuscation present on the external script raises an eyebrow here.

Unfortunately the problem is already here... your current implementation of your script covers up linkage already on small viewports. Nice for full width devices though. When affecting the base code decisions should be based on the whole experience not just one. :)

Re: @trespassersW:

Interesting alternative in your script now... however what happens if there are multiple reminders? What happens on extremely small viewports?

Re: @shuffyiosys:
Operas native implementation has been removed from newer versions since their switch to the Chrome/Chromium backend.

Re: @weronikaalot:

Care to elaborate a bit more on this? What does "500" and "5000" mean in context. Thanks.

timeout isn't the best solution, IMO

Neither is leaving an open ended statement as such... seems to be lacking merit at the moment.

Well it's what everyone is stuck with until someone creates an issue properly on development and someone picks up the task of doing it. If you are that impatient with it then get to work!... or wait until the expiration date when you won't have to worry about it. I've already presented you with what could be, including my intentional absence of mentioning cookies. ;) I guarantee a later label as I'm done with it for the time being but that doesn't mean we won't examine what is presented formally and any PRs. So hop too it, IMO. :)

I understand this is your test but you still need to comply with the Terms of Service (TOS) regarding cross-site usage of UserScript metadata blocks. You have about one day to fix this before I remove it permanently. Thanks.

Re: @trespassersW:

... cookies.

Rather use localStorage if it boils down to that... cookies are usually managed with several peeps too. My DOM storage is disabled so that's why it won't work for me. GM_setValue in a user.js is technically the only user safe way to do this other than creating a full reminder model (which isn't out of the question but not a top priority for me at the moment due to putting out other fires).

Re: @trespassersW:

Can I close it once and for all?

I'm considering a timeout or using a localStorage value to indicate that it's been read (which won't work for some including me)... I may even entertain a temporary user.js in the short term but everyone else who doesn't visit as often as some needs to see it... and I'm still working on some other areas related to this. It is closable... got any other ideas? :)

Guess what... another test.

Re: @Marti:
You don't say. ;)

Re: @Marti:
Retest

Retest

Google has deprecated OpenID and will End-of-Life (EOL) this authorization method by April 20th, 2015.

OpenUserJS.org has made some accommodations to automatically migrate from OpenID to OAuth2. We'll be observing this change for the next few days to ensure everything is good to go on our end. You should be re-prompted for access to your Google profile to confirm this change.

• If your primary account is Google for registering you will want to log in before that date! After that date you will most likely lose access to your account here if you don't do this... as we will have no way of knowing who you really are, any requests for migrating your account manually will not be accepted... so please login to have our system migrate it at your earliest convenience.
• We would also suggest if you have Google as a secondary authorization that you switch to it temporarily and then switch back to your preferred primary authentication. This can be done currently at your preferences and you shouldn't need to logout for this process.
• New accounts should automatically be OAuth2.

Thank you for a moment of your time.

Retest

Fixed in 3574fcc. Thanks.

$('#srp_adsense-top, #srp_adsense-middle, #srp_adsense-bottom, #srchrslt-adtable-topads, .headerbox.t-border-yellow, #home-gallery).remove();

... should be ...

$('#srp_adsense-top, #srp_adsense-middle, #srp_adsense-bottom, #srchrslt-adtable-topads, .headerbox.t-border-yellow, #home-gallery').remove();

... notice the missing apostrophe (quote) towards the end on current line 70.

Mirrored at 7484c36.

Please check your JSHint messages in the left gutter of the Source Code tab next to the line numbers. In this case some of them are quite accurate. Thanks. :)

Re: @cuzi:

Cookie Controller enabled, which blocks cookies and DOM storage.

Yup that is partially it. Thanks for that... save me some time next week. :)

, which blocks cookies and DOM storage.

When disabled my Firefox (Fx) takes over since that Add-on uses the existing about: prefs e.g. the settings persist.

as this addon is not really popular.

There's also about:data in SeaMonkey (SM) so it's quite common for some browsers, especially Moz, to have these settings enhanced. Fx is about:permissions.

Re: @jgjake2:

Anything in particular you want included?

So there's one thing... fallback to DOM storage e.g try using the GM_* API first and if all else fails perhaps let the user know gently... perhaps with console.warn statement or better. This is how one of our earlier projects works.

Re: @jgjake2:

What kind of add-ons do you have?

Lots... will have to narrow it down to which ones as well as about:config changes. Like I said earlier I don't have enough time just yet to do the Add-on walk-about testing. Perhaps sometime next week will work for me.

What pops up in your console?

unsafeWindow and localStorage is what I recall from earlier... again depends on what active Add-ons I had. NoScript is the usual culprit for enforcing certain security restrictions but Moz is taking on that challenge as well. Will take some time to iron out the details for you... but not until at least next week.

Anything in particular you want included?

Don't know yet... testing stopped once the Add-on incompatibility was discovered. I'll try to redo my profile in case migration is a factor in the results... that takes a bit to do.