Just had an unpleasant re-surprise (was only half-awake, so didn't take full usual precautions against double-posting from Oook RGRA portal). Note that I normally use the dedicated RGRA login rather than the forum login.
I am not used to the following sequence generating a post:
* being asked to login in, so...panic; instead of filling out the login form per correct checklist on my end, hit the back button (to recover post content; panic precludes noticing that I just copied the whole post content into the clipboard just-in-case).
* Blank post composition screen comes up rather than the content of the intended post (ok)...*but* the post gets sent out anyway (bug).
The back button not only re-logged me in (not normal behavior for a web application, but can be caused by appropriate http headers), it sent out the original composed post as well (exceptionally not-normal behavior) without suggesting it had done so (bug).
This isn't the first time this has happened to me when half-awake. It just occurred to me that this combination of features would also cause double-posting for RGRA portal newbies used to standard web application back button behavior.
Does the architecture permit a quick alteration that does exactly one of the following:
* blocks posting when the back button is used?
* correctly informs the user that their post has been submitted to USENET?
Target browser is SeaMonkey 1.1.7; FireFox was forked from SeaMonkey back when SeaMonkey was the Mozilla suite.
I am not used to the following sequence generating a post:
* being asked to login in, so...panic; instead of filling out the login form per correct checklist on my end, hit the back button (to recover post content; panic precludes noticing that I just copied the whole post content into the clipboard just-in-case).
* Blank post composition screen comes up rather than the content of the intended post (ok)...*but* the post gets sent out anyway (bug).
The back button not only re-logged me in (not normal behavior for a web application, but can be caused by appropriate http headers), it sent out the original composed post as well (exceptionally not-normal behavior) without suggesting it had done so (bug).
This isn't the first time this has happened to me when half-awake. It just occurred to me that this combination of features would also cause double-posting for RGRA portal newbies used to standard web application back button behavior.
Does the architecture permit a quick alteration that does exactly one of the following:
* blocks posting when the back button is used?
* correctly informs the user that their post has been submitted to USENET?
Target browser is SeaMonkey 1.1.7; FireFox was forked from SeaMonkey back when SeaMonkey was the Mozilla suite.
Comment