Potential filter bug after changing page selector

[gregoryfoster]

Thanks for building such an excellent tool for many different use cases. I'm starting this question as a Discussion as I'm not sure where a support case should go, and I might be surfacing a bug.

I'm watching several instances of one screen (legislation in Washington state). I have an overall selector, and then I remove two variable page elements (one by class, one by ID). That's worked well for the past year.

The page was recently changed where the overall selector is different, but the variable page element selectors remain the same. But now the selector by class isn't working.

Here's an example screen:
https://app.leg.wa.gov/BillSummary/?BillNumber=1551&Year=2025&Initiative=false

CSS Filter: .bill-summary-page
Remove Elements:

• .asOfDateContainer (was previously working, not working now)
• #videoSection (still working)

I've tried being more specific (div.asOfDateContainer) and cloning the watch, but no dice. Notifications are clogging up my inbox with false positives since that date field is different on every check. Super weird since it worked just fine previously and nothing has changed in the HTML. Any help would be appreciated!

[dgtlmoon]

Heya!

yeah I have seen something similar, can I ask - did you create the filter with the "Visual Selector" first? does it involve filters from Visual Selector?

[gregoryfoster]

Thanks for your reply! As I recall, I did not use the Visual Selector first - and definitely would not have across the 50-60 similar watches.

[gregoryfoster]

Any workarounds for this? I'm getting 46 false positives in my inbox + Slack notifications daily.

I previously tried cloning a watch and that made no difference.

Today I tried creating a new watch for one of my target URLs from scratch, and that also failed which is not what I would expect. I tried changing the selector to the containing <div> (.statusAtAGlanceHeader) and that also did not work.

Next I tried create a new watch for a comparable screen that I had NOT previously targeted. That ALSO failed, which really isn't what I would expect, and indicates something more broad-based might be at issue? The notification diff is dutifully reporting the changed .asOfDateContainer I've asked to remove from consideration, so the targeted content remains present. Perhaps class name selectors aren't working to remove elements for some reason?

[gregoryfoster]

@dgtlmoon, as a subscriber to your service, I'd appreciate a review of this discussion and update.

[dgtlmoon]

@gregoryfoster I see your message, i'll take a look, please can you send us a support email with your login details? (use the form on the front page of changedetection.io ) thanks

[dgtlmoon]

So there's two, and one is hidden usually except it's shown in the HTML-to-text stage

            <div class="asOfDateContainer">
                    As of Friday, September 19, 2025 06:41 AM
            </div>

and

<div id="billStatusAtAGlanceSmall">
            <div class="header">
                <div>
                    <div class="statusAtAGlanceAsOfSmall">
                        As of Friday, September 19, 2025 01:53 PM
                        <a style="font-size: 0.7em" href="[#](https://app.leg.wa.gov/BillSummary/#)" data-bs-toggle="modal" data-bs-target="#abbreviationPopup" class="statusAtAGlanceHelpIcon" onclick='WSLApp.StatusAtAGlanceHelp.populateContent()'>
                            <img src="[/BillSummary/images/BillSummaryInfoIcon.png](https://app.leg.wa.gov/BillSummary/images/BillSummaryInfoIcon.png)" />
                        </a>
                    </div>
                </div>
            </div>

you need to also add .statusAtAGlanceAsOfSmall as a removal filter.

Solution B.

the work around is to put As of into "Ignore lines containing"

does that help you? it will go to a grey background which means its ignored when generating the change detection (that line)

[gregoryfoster]

Thank you very much for identifying this issue and resolution. Looking for a wholly separate instance of the variable date/timestamp elsewhere on the page hadn't occurred to me. A closer reading of the output shows it was there all along and as usual the (deterministic!) computers were doing exactly what we told them to do. Thank you!

[dgtlmoon]

I'm just glad theres nothing weird going on in the subtractive filters :D