@Ollie That feature is AIM. FIRE will show the overall reason weight total as part of the why display, but to get the information is part of the reorganization of how FIRE (and AIM) get data for the posts. Those changes are part of the blocks of code which haven't made it into the released versions yet (and still need a bit of work).
@Spevacus Yep, FIRE now indicates it's received the click and doing something, so you don't keep clicking on it thinking nothing's happened. :;
@Makyen In this case, that icon was forever performing its load action when I attempted to open FIRE in a room I did not have a token to use FIRE in (or I didn't have access to feedbacking in that room, whatever... words) - Closing the dialog didn't stop the rotation, and I'm assuming that's because in openReportPopup when it checks for a MS Write token, if it comes back false, it doesn't make a clearFireButtonLoading($fireButton) call the same way it does if the load timeout is hit.
@tripleee That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command if you really want to add this pattern.
@Spevacus OK. Let me take a look at it. I'm not too surprised there's a corner case or two, or three, that aren't covered. IIRC, it should go away if you successfully open another post/report.
@Spevacus Yeah, but it should be an easy fix, and there's not a whole bunch of cruft in the way (i.e. I'm not a hundred, or so, commits into another branch where I'd have to resolve merge conflicts if I make some other change).
@Spevacus Thanks. I'm glad you, and others, like them. I wish they had happened much sooner.
I'll be very glad to get things back to being relatively even wrt. what's in my development version and what's in the release version. I really allowed the disparity there, that mainly started with not being permitted to have FIRE send flags through the SE API, as that and associated changes affected how things were handled in a large part of the code, to get well beyond what's reasonable.
[ SmokeDetector | MS ] Bad keyword in answer, link at beginning of answer, potentially bad ns for domain in answer, potentially bad keyword in answer (123): The remote computer requires NLA by jack on serverfault.com
@double-beep What you listen to is up to you. That event will fire when the popup is actually open and in the DOM. That event fires on the FIRE button which was used to open the popup. The data payload contains the data which FIRE has for the post (minus some sanitized portion which is obtained using the user's SE token). The fire-popup-opening event is fired when FIRE starts the opening process and does not contain data.
There's an additional event fire-popup-opening-have-data which fires a bit later in the opening process, but after FIRE has data. Of those, which one you use is up to you, depending on when you want to start reacting and what you're doing.
I'm also planning to just have some data events and/or a way to request data be fetched, but those are still in planning. I am, of course, also willing to make changes which would help you, if you have things you'd like to see.
I don't know if you're using fire.reportCache, but the organization to that is going to change, as organizing it by URL doesn't really allow for the reality of multiple reports for the same URL. In other words, the plan is to transition to (mostly) using MS post IDs, but it gets complex fairly quickly.
@double-beep In upcoming changes, the MS post ID will be stored as an data attribute on the FIRE button. FIRE does the the work of determining which MS report matches with that FIRE button (which is somewhat indeterminate). The goal is to have that determination done in one place and allow any other userscript to remain consistent (e.g. not have AIM merge feedbacks across multiple reports for the URL).
The goal is also to not have multiple userscripts, well at least both FIRE and AIM, separately fetching similar data from MS about the same posts/URLs.
@Makyen Looks like with AIM, when a user gives feedback via a chat message (cigien's, above) and then another user gives feedback via FIRE or review (me, ^^^^), it only shows that the user who used the app or review has given feedback. Bug?
@Ollie The information AIM displays is entirely based on what it receives from the MS WebSocket. AIM never attempts to verify that the record it's maintaining hasn't become inconsistent with what's actually on MS. That has a variety of issues which easily result in not maintaining consistency under some circumstances (e.g. just a missed WebSocket message). While I plan to address that, primarily by having FIRE maintain that consistency and passing the data to AIM, that's not currently done.
I'm not aware of there being any consistency issues which were added by the recent changes, but it's possible that there were some. Unfortunately, I didn't see a problem with the specific report/chat message which you're asking about. My main profile and all the other browser profiles in which I have a tab open to CHQ with FIRE and AIM running show the correct number of feedbacks on that post. So, at the moment, I'd assume this was a brief networking glitch for you.
@Ollie Ahh... I think I may have misunderstood what you were reporting. You mean the names displayed in the tooltip for the feedback type, not the total number of feedbacks (i.e. that there's a feedback in the total which isn't reflected in the tooltip).
@Ollie OK. Yes, I see that. I'll look at it. I assume that the data isn't provided by MS, or that the format for the WebSocket message is somewhat different.
@tripleee That pattern looks like it's already caught by Bad phone number in body and Bad phone number in answer Append -force to the command if you really want to add this pattern.
@tripleee That pattern looks like it's already caught by Bad phone number in body and Bad phone number in answerThe pattern starts with whitespace. Append -force to the command if you really want to add this pattern.
