On the Mozilla Firefox Watchlist, is there a way to keep a recorded change notification available for longer than until the system performs the next change check? When a change occurs, a change notification briefly appears under ‘Unread’, but only for a very short period of time—it is removed the moment the system performs the next change check, WITHOUT having been read (nor are the missed notifications transferred to the ‘Error’ or ‘Trash’ folder). This means I often miss notifications, especially when I am away from the computer; when I return to the computer there is NOTHING to indicate that a change has been recorded. Can the settings for ‘Unread’ be changed? If not, does Distill for Firefox have the functionality to look up the ‘change history’ in some other way?
If conditions are added:
- When a change is detected that matches the condition, the monitor will be marked as unread.
- If a subsequent change is detected that does not match the condition, the monitor will be marked as read.
Can you verify if any conditions have been added?
If no conditions are added, the monitor will be marked as unread for any change until you read it.
Yes, I do use conditions.
As the webpage I try to monitor undergoes VERY FREQUENT change (every few minutes or so), but only VERY RARELY the change that matches the condition (only once every 48 hours or so), it appears that the monitor is marked as ‘Unread’ for only a few minutes at best each time before the recorded change (that matches the condition) is removed (namely at the next change that does NOT match the condition).
This means there is almost never enough time to spot that a change (that matches the condition) has taken place, which completely defeats the purpose of monitoring the webpage.
I wonder whether Distill has a record of PAST / HISTORIC changes (that MATCHED the condition), or whether all records of such changes are IMMEDIATELY AND IRRETRIEVABLY lost the moment a change (that does NOT match the condition) is detected (ie within minutes, in my case).
If not, then a feature change that keeps all changes (that match the condition) listed under ‘Unread’ until they have ACTUALLY been read would be extremely useful. How else would I even know that a change (that matches the condition) has taken place, unless I sit at my computer all day long, which I don’t?
This behavior seems very strange and unintuitive to the user.
The default condition is “any change”. The monitor behaves properly here.
The addition of condition changes the default condition, but should not change the behavior of the notification.
I would also like to monitor a page that changes frequently, but only care about some of the changes.
Currently, if I don’t see the change in time, it would be marked as “read”, for no reason.
Is there a way to change this behavior?
it is actually quite useful for many using conditions. it suppresses noisy changes that could appear as an unread item in the list.
this is definitely a problem when someone is away and has not setup any other notification channel like emails or discord.
one possible solution we can think of is to not mark the monitor as read if an only if the monitor was unread before the change was most recent change was detected.
if the change that marked the monitor as unread is no longer in the change history, one can’t see that change even if monitor is unread. if all of the change that trigger an alert conditions are important, a persistent channel of notification like email, discord or push notification will be work well in all cases.
thanks for sharing the feedback. cheers!
@azuredarkness this was recently shipped in version 3.10.22. cheers!
To be honest, it would have been better to create a poll to ask users for their opinion on this “new behavior,” or at least allow users to configure it in their settings so that each user can decide how they want to view the monitors.
Right now, I’m completely lost—all my monitors are marked as “unread.” I can’t be 24/7 (constantly) marking everything as read, so when I’m on the dashboard and see an unread monitor, I assume that the latest change is highlighted because it triggered one of my conditions. However, when I check the last change, it hasn’t even triggered an alert.
I strongly suggest reconsidering this approach.
thanks for sharing the feedback @elbeborandy2. as others have suggested, the old behavior is surprising for due to the reasons outlined above. not being able to see an important change that was triggered in the past is a big shortcoming. it had to be fixed.
we are open to offering an option that lets one opt-in to the old behavior (to mark monitor as read if the latest change doesn’t match the condition). keeping this thread open for others to chime in. if there is a strong support by other users too, we will add an option.
Nice, that would be great.
I think the new behavior is helpful for users with just a few monitors. But in my case, I have over 100 monitors running, so it’s impossible for me to mark them as read every time. 
Thanks for understanding
I’m surprised to find that I’m the only one experiencing difficulties with the new behavior. I’m not sure if you’ve received any feedback via email, but I kindly suggest considering an option where users can choose the behavior that best suits them. After all, this change impacts the user experience, so it would be great if we could have some control over how it appears on our end.
Thank you for your attention to this.