offline-qr-code
offline-qr-code copied to clipboard
The "like addon" tip is too aggressive/too often shown
Bug description
Steps to reproduce
- Generate a code
- dismiss tool-tip in pop-up
- it happens again next time, or 2nd or 3rd
Actual behavior
The tool-tip will not stop.
Expected behavior
I would like to see no more tool-tips at all.
System
Operating system and version: Browser and version: Firefox Add-on version:
Possible solution
Please allow to disable tool-tips completely. It might be easier than writing code to memorize if they were already shown. They are useful, but for advanced users they are a little repetitive and make me sad.
Thanks for your report.
It might be easier than writing code to memorize if they were already shown.
Actually, that should already be implemented.
However, it is calculated for each tip and there is a minimum (aka required count/dismissing count) and maximum count of dismisses: https://github.com/rugk/offline-qr-code/blob/a0193ba1f1c5f90b06b6e99b9a5973b69d850e21/src/common/modules/data/Tips.js#L93-L94
What the values mean exactly is documented in the code directly: https://github.com/rugk/offline-qr-code/blob/a0193ba1f1c5f90b06b6e99b9a5973b69d850e21/src/common/modules/data/Tips.js#L11-L16
So it's all a little more complicated, but as far as I read it there after two dismisses the given tip is very certainly never shown again. On the other hand, as you can see, this can be tweaked in all details. :upside_down_face:
I tried to be conservative, but allow for a "second chance" for important tips, so if you click it away (e.g. because you currently have no time for that), you can see it later at least once. Note there is also a general limitation with a chance of 20% that any tip is shown at all, so in 4 of 5 triggers (popup openings in this case), you should – statistically – not see any tip at all.
To help debug this, could you please go to about:debugging#/runtime/this-firefox
in a new tab of Firefox, find the add-on in gthe list, click debug and then enter await browser.storage.sync.get("randomTips");
in the console there and copy the result (be sure to include the full object via right click -> "copy object") here. It shows the recordings of the add-on regarding what was shown, dismissed etc. how often etc.
Then please explain which tip is annoying you here, and which was shown too often… :wink: :upside_down_face:
{
"randomTips": {
"tips": {
"translateAddon": {
"shownCount": 2,
"dismissedCount": 1,
"shownContext": {
"popup": 2
}
},
"androidQrReader": {
"shownCount": 0,
"dismissedCount": 0,
"shownContext": {}
},
"likeAddon": {
"shownCount": 36,
"dismissedCount": 1,
"shownContext": {
"popup": 35,
"options": 1
}
},
"saveQr": {
"shownCount": 8,
"dismissedCount": 1,
"shownContext": {
"popup": 8
}
},
"qrCodeHotkey": {
"shownCount": 1,
"dismissedCount": 1,
"shownContext": {
"popup": 1
}
}
},
"triggeredOpen": 69
}
}
The "like this addon" tool-tip was shown too aggressively, in agreement with your internal counters. I can only give you my word I dismissed it with "X to close" in the tip-menu itself more than once (perhaps 8 times, I simply gave up). I think it needed a browser restart to show effect (regarding the data in sync-v2.sqlite). I still see it sometimes like earlier today. But now it seems to have stopped.
If there is a flaw with your code (or my browser) the restart is what fixed it. I didn't have the chance to close it yesterday as I was running a large file transfer.
Hi and thanks a lot for the data.
Yeah, according to the data, you only dismissed it one time and it is supposed to be dismissed at max two times (edit: actually at max two times, but at least one time, which your data shows, happened), so well… it showed it 36 times, which I totally agree is way too aggressive… :upside_down_face:
If there is a flaw with your code (or my browser) the restart is what fixed it.
Yeah, I guess it is some caching bug, as the AddonSettings
by default cache the settings.
Though new settings should be saved to cache and we actually properly save the dismiss when it is triggered, otherwise the one dismiss also would not have been saved.
However, the website the add-on loads is totally reloaded anyway when you open a popup.
Did you maybe mix the "dismissed in popup" and "dismissed on options page"? (Maybe even when having both open at the same time… :upside_down_face:) Or were all dismisses only on the popup page? (I mean the data shows it was shown at least once on the options page.)
I didn't have the chance to close it yesterday as I was running a large file transfer.
However, when your settings are from your current browsing session, ~~the problem should still be there.~~ Ah, no dismissedCount
is 1 and requireDismiss
is 1, so it should never be shown again.
Hint: BTW, if you reset the options on the options page, all counters like these are also cleared (basically all data is cleared :upside_down_face:), so be aware of that (or, if you want to reproduce it, you can also do that deliberately of course).
So if it happens again, a copy of the console log would be very helpful. (again the context menu provides a "export -> to clipboard" option so you can copy everything with a proper formatting)
When you can reproduce it, it would be great to get the log from about:debugging
again as described before. However to debug a popup you need to disable popup hiding on click before accessing the dev tools.
Note the sentence, so you may need to choose the correct HTML first (It is named popup/qrcode.html
or so :upside_down_face:):
click the page select icon (
) to open the popup's document
I have given it some thought what actually went down here:
Considering that the last update was on Nov 20th, this is part of why I believe my Firefox ESR is part to blame. (Did I reset the addon?) However, on the other end, when I tried to dismiss it again, it would poorly react without a restart after dismissing it.
Your reply tells me the dismiss counter should be reading 2 by now, which it did not, and I am very sure I have dismissed it more than that.
Hint: BTW, if you reset the options on the options page, all counters like these are also cleared (basically all data is cleared 🙃), so be aware of that (or, if you want to reproduce it, you can also do that deliberately of course).
I am willing to try that and see if the problem is reproducible. After all I don't like opening issues and then ghost the dev.
Test done: Okay I have dismissed it 8 out of 9 times and it still keeps showing. I doubt without a restart it will respect me dismissing it. Do note the integer reads 1 despite many tries.
{
"randomTips": {
"tips": {
"qrCodeHotkey": {
"shownCount": 3,
"dismissedCount": 0,
"shownContext": {
"popup": 3
}
},
"translateAddon": {
"shownCount": 0,
"dismissedCount": 0,
"shownContext": {}
},
"androidQrReader": {
"shownCount": 0,
"dismissedCount": 0,
"shownContext": {}
},
"likeAddon": {
"shownCount": 1,
"dismissedCount": 0,
"shownContext": {
"popup": 1
}
},
"saveQr": {
"shownCount": 9,
"dismissedCount": 1,
"shownContext": {
"popup": 9
}
}
},
"triggeredOpen": 15
}
}
Edit:
When you can reproduce it, it would be great to get the log from about:debugging again as described before. However to debug a popup you need to disable popup hiding on click before accessing the dev tools.
That made the behaviour work as intended for some reason. The popup could only be closed with escape, but when I exported the JSON structure it would show these integers now:
{
"tips": {
"androidQrReader": {
"shownCount": 0,
"dismissedCount": 0,
"shownContext": {}
},
"qrCodeHotkey": {
"shownCount": 1,
"dismissedCount": 1,
"shownContext": {
"popup": 1
}
},
"translateAddon": {
"shownCount": 0,
"dismissedCount": 0,
"shownContext": {}
},
"likeAddon": {
"shownCount": 1,
"dismissedCount": 1,
"shownContext": {
"popup": 1
}
},
"saveQr": {
"shownCount": 2,
"dismissedCount": 2,
"shownContext": {
"popup": 2
}
}
},
"triggeredOpen": 11
}
I have also felt that they come up way too often, and they also override your own settings making them very invasive. I also never understood that they could actually be dismissed.
You could perhaps disable them permanently after they have been shown 10 times, or add a tooltip: "Dismissing a tooltip will make it go away permanently".
Also, I'm not a fan of the tooltip overriding user settings to display themself in full width like this, it makes them feel intrusive.
Actual behavior
![]()
![]()
I guess this can be closed.
If you feel so. Also BTW the width is just the text-width it needs to display the tip, there is not a lot I can do, it has the width and takes it, as expected.
You could perhaps disable them permanently after they have been shown 10 times, or add a tooltip: "Dismissing a tooltip will make it go away permanently".
The last thing is not actually true. As explained before, in this case, it must be dismissed at least once to be never shown again and if it has been dismissed twice or more it is shown again. (with the current settings) The thing is to hide this complexity from the user and just provide unobtrusive, but contextually helpful tips.
For anyone else to debug thus, how to get the data I need is described in the post I already linked. Without that, this is hard to debug – by design, after all, as it is very "random" depending on many factors, that were included in the library.
The thing is to hide this complexity from the user and just provide unobtrusive, but contextually helpful tips.
If that is your wish a small icon (maybe with a question mark) and a moz-extension://
html page with further information about using/supporting/helping the addon would help better. Developers usually have different views than users. Many people remember "Karl Klammer" or "Clippy" from Word. For me tooltips usually have the opposite effect from negative conditioning.
I'd rate this addon 5 stars, it's amazing, but making an addons mozilla account just for that is unlikely. To explain my feelings about such a notification. Other developers show a pop-up tab after updates like Tampermonkey. I just find it hard to talk about this, since this is your addon and you run this show however you want. So I don't know if my opinions are helpful.