Editing posts is broken

[kunkel321]

Only if you type in a hurry, make mistakes and realize just after you submit that you need to edit - more than once.

This is me in a nutshell!

Okay, will try editing...

nope... First edit disappeared. (this is second edit)

[kunkel321]

fyi screenshot...

Made reply, then did EDIT 1. Then edited a second time and the editor didn't have the "EDIT 1" in it. Typed the second message and got this when I clicked submit again:

[joedf]

Only if you type in a hurry, make mistakes and realize just after you submit that you need to edit - more than once.

This is me in a nutshell! [...]

Glad to know I'm not alone on this ahaha

@kunkel321 Thanks, maybe the theme also changes something?
I'll try MS edge and see... Can you try another browser as well?

EDIT: Okay! I can confirm it happened very reliably on MS edge for me. but everything is fine on firefox...
Can someone try firefox or some other non-chromium browser to confirm?

[kunkel321]

Okay, Installed FireFox and posted this...
edit 1
edit 2
edit 3
and edit 4 -- Apparently it's a Chrome issue! FF seems faster too.

Just did "edit 5" using Edge browser, and it apparently didn't stick...

[joedf]

Awesome, thanks! While I generally do prefer and recommend Firefox myself, I respect that others can and will use chrome if they prefer haha
So I will see if I can use this knowledge to track it down... but at least there's a workaround for now

[joedf]

Okay, so I think my idea may be correct. It is chrome's aggressive caching,
One workaround for chromium browsers is to simply hit refresh (or Ctrl + R) after you enter the edit post page.
The textbox will then have the updated text. I think this is a recent change or bug with Chrome.

I have not tracked down the version from where this behaviour starts appearing. Could all of you share your exact chrome or browser versions? even if they've been updated. At least, it will give me an upper limit.
Mine is Microsoft Edge Version 130.0.2849.80 (Official build) (64-bit)

[RussF]

@joedf, I can confirm that refreshing F5 as soon as you re-enter the editing screen for the nth time does work. I tested on my first message in this thread - edited post, submitted, immediately edited, change not there, F5, change appeared.

My Chrome version is 130.0.6723.117 (Official Build) (64-bit)

Thanks for all your efforts!

Russ

[TAC109]

I was using the Safari browser on my iPad when I encountered this problem, so I believe the error is more likely to originate at the server end. Just testing now and the problem still exists for me. Refreshing the window does circumvent the problem.

Cheers

[kunkel321]

Will try the 'refresh' trick in Chrome here....
Edit 1...
Edit 2: Sure enough... This is the second edit. When I opened the editor (to edit the already-existing reply), the "Edit 1.." was not there. Then I pressed F5 and it appeared.

Thanks for your work on this Joe!

[RussF]

As an aside, this whole 'refresh' issue must be intrinsic to most BBS systems. Every one I frequent behaves the same. When I read a topic, then either click the 'back' arrow or (preferably) press the 'back' button on my mouse, the highlight on the topic title does not go away to indicate that I have read it. I must either refresh with F5 or scroll all the way down and click the 'Return to ...' link. I finally added a section into my "Standard Hotkeys" AHK script (that loads when I log in and is always running) that triggers off of XButton1 (the mouse 'back' button). Using GetUrl() from anonymous1184, I check the current URL. If it belongs to one of my forums, it sleeps a bit to give the page time to load, then issues an F5 to refresh.

For some unexplained reason, it usually takes 3 or 4 uses first thing in the morning to start working, but then it's about 95% effective. I'm happy with it regardless.

Here's the code if anyone is interested. It's in V1 because my whole 'Standard Hotkeys' script has been evolving over the past few years and I haven't converted it. Hey, if it works, don's fix it!

Code: Select all

#Requires AutoHotkey v1.1.33+

#IfWinActive ahk_exe chrome.exe
    ~XButton1::
        Sleep 300
        ActiveUrl := GetUrl()
        If (InStr(ActiveUrl,"autohotkey.com/boards/"))
            SendEvent {F5}
    return
#If

; Version: 2023.10.05.1
; https://gist.github.com/7cce378c9dfdaf733cb3ca6df345b140
; Courtesy of anonymous1184

GetUrl() { ; Active Window Only
    static S_OK := 0, TreeScope_Descendants := 4, UIA_ControlTypePropertyId := 30003, UIA_DocumentControlTypeId := 50030, UIA_EditControlTypeId := 50004, UIA_ValueValuePropertyId := 30045
    WinGet hWnd, ID, A
    WinGetClass winClass, A
    eRoot := condition := eFirst := 0
    IUIAutomation := ComObjCreate("{FF48DBA4-60EF-4201-AA87-54103EEF594E}", "{30CBE57D-D9D0-452A-AB13-7AC5AC4825EE}")
    HRESULT := DllCall(NumGet(NumGet(IUIAutomation + 0) + 6 * A_PtrSize), "Ptr", IUIAutomation, "Ptr", hWnd, "Ptr*", eRoot)
    if (HRESULT != S_OK) {
        throw Exception("IUIAutomation::ElementFromHandle()", -1, HRESULT)
    }
    ctrlTypeId := (winClass ~= "Chrome" ? UIA_DocumentControlTypeId : UIA_EditControlTypeId)
    VarSetCapacity(value, 8 + 2 * A_PtrSize, 0)
    NumPut(3, value, 0, "UShort")
    NumPut(ctrlTypeId, value, 8, "Ptr")
    if (A_PtrSize = 8) {
        HRESULT := DllCall(NumGet(NumGet(IUIAutomation + 0) + 23 * A_PtrSize), "Ptr", IUIAutomation, "UInt", UIA_ControlTypePropertyId, "Ptr", &value, "Ptr*", condition)
    } else {
        HRESULT := DllCall(NumGet(NumGet(IUIAutomation + 0) + 23 * A_PtrSize), "Ptr", IUIAutomation, "UInt", UIA_ControlTypePropertyId, "UInt64", NumGet(value, 0, "UInt64"), "UInt64", NumGet(value, 8, "UInt64"), "Ptr*", condition)
    }
    if (HRESULT != S_OK) {
        throw Exception("IUIAutomation::CreatePropertyCondition()", -1, HRESULT)
    }
    HRESULT := DllCall(NumGet(NumGet(eRoot + 0) + 5 * A_PtrSize), "Ptr", eRoot, "UInt", TreeScope_Descendants, "Ptr", condition, "Ptr*", eFirst)
    if (HRESULT != S_OK) {
        throw Exception("IUIAutomationElement::FindFirst()", -1, HRESULT)
    }
    VarSetCapacity(propertyValue, 8 + 2 * A_PtrSize, 0)
    HRESULT := DllCall(NumGet(NumGet(eFirst + 0) + 10 * A_PtrSize), "Ptr", eFirst, "UInt", UIA_ValueValuePropertyId, "Ptr", &propertyValue)
    ;if (HRESULT != S_OK) {
        ;throw Exception("IUIAutomationElement::GetCurrentPropertyValue()", -1, HRESULT)
    ;}
    ObjRelease(eRoot)
    ObjRelease(condition)
    ObjRelease(eFirst)
    ObjRelease(IUIAutomation)
    try {
        pProperty := NumGet(propertyValue, 8, "Ptr")
        return StrGet(pProperty, "UTF-16")
    }
}

Russ

[joedf]

Okay, looks like Google has change how installers work, and we can no longer download and install previous versions of google chrome.
The last installer version available I found was v105 on filehippo which is too old. I also checked to see if they have a public issue tracker, but it looks like they dont.
This makes it significantly harder to track down bugs...
I looks like our only options are reporting a bug from the browser like so: https://support.google.com/chrome/answer/95315?hl=en&co=GENIE.Platform%3DDesktop
Or to build Chromium from source which has no guarantee it will work...

They are closed source, making it more difficult...

I ask that you all report the issue with the link above. Hopefully, we can be loud enough. This problem seems to be caused by chrome's aggressive caching.

EDIT:
I've found Chromium's issue tracker here.
https://issues.chromium.org/issues

and versions lists here:
https://chromiumdash.appspot.com/releases?platform=Windows

and how to download old versions here:
https://www.chromium.org/getting-involved/download-chromium/#chrome-for-testing

Hopefully, I can reproduce it here...

EDIT2: I went all the way back to v113.0.5672.63, still happened... Seems like Firefox and chrome just handle something differently... So maybe there is some server config than can get around this... not sure.