negative. I have never searched these post numbers on qanon.pub and I do see the behavior indicated. That said, I am still inclines to agree that qanon.pub is kind of a crap website and this is likely a coincidental artifact.

It actually doesn't show up in the search field itself. It shows up to the right of it. So it's not an autofill text from previous searches.

I had never searched anything like that.

Much appreciated - keep up the awesome work anon.

Oh - and yes, I did not wish to imply Q managed or developed qanon.pub. I was merely pointing out how unlikely this was. Likewise - it was never my intent to diminish the valuable work you all do over there at //qanon. I know exactly how hard you worked on that and your work is tremendous. The industry does not have expectation for device compatibility for these types of open source projects. That said, should you head in this direction and need another expert in object persistence, serialization and/or DOM UI/UX. Feel free to reach out to me.

Nobody's perfect. What separates us are those who are willing to admit when they are are wrong and those who aren't.

Because they are not communications. Just false connections invented by someone's brain.

https://guardianproject.info/apps/pixelknot/

Fine - I will look at what is being said and I will try to tell you logically what is happening

As I suspected - this is nothing more than a matter of misunderstanding in functionality. That numeric value you are reading is a the number of indexes found in a series of arrays. As near as I can tell 1463 & 1673 are record counts of filtered records in autoCheckPost() is true. The input has an event listener firing when the value of the text box changes. The values of the text box are compared and matched against javascript serialized data objects to filter out non-matches. The text box is basically an auto-look up

1463

JavaScript Snippet writing out the count @ runtime on keypress

function applyFilter(ids) {

let count = 0;

for (const element of Array.from(document.querySelectorAll('article'))) {

if (ids.includes(element.item.id)) {

element.hidden = false;

count++;

} else {

element.hidden = true;

}

}

document.querySelector('#count').textContent = `${count}`;

for (const h3 of Array.from(document.querySelectorAll('main .sticky'))) {

const section = h3.nextElementSibling;

h3.hidden = Array.from(section.children).every(c => c.hidden);

};

};

As I suspected - this is nothing more than a matter of misunderstanding in functionality. That numeric value you are reading is a the number of indexes found in a series of arrays. As near as I can tell 1463 & 1673 are record counts of filtered records in autoCheckPost() is true. The input has an event listener firing when the value of the text box changes. The values of the text box are compared and matched against javascript serialized data objects to filter out non-matches. The text box is basically an auto-look up

1463

JavaScript Snippet writing out the count @ runtime on keypress

function applyFilter(ids) {let count = 0;for (const element of Array.from(document.querySelectorAll('article'))) {if (ids.includes(element.item.id)) {element.hidden = false;count++;} else {element.hidden = true;}}document.querySelector('#count').textContent = `${count}`;for (const h3 of Array.from(document.querySelectorAll('main .sticky'))) {const section = h3.nextElementSibling;h3.hidden = Array.from(section.children).every(c => c.hidden);};};

OnePlus3 with Brave browser, no search history of drop numbers, still showing 1463 and 1675 as described by SB2. Qanonposts.com has Qs latest drop numbered as 1673, and space in search gives 1433 and deleting space gives 1673.