Half the time I click on "Save Page" the next screen is a "Preview" (and my edits are not yet saved). I have been careful about this, and am definitely clicking on "Save Page," not "Show Preview." And this is happening a lot.
Is this happening to anyone else, or is it just me?
Does anyone have any idea why it is happening?
Steve
Steven L. Rubenstein Associate Professor Department of Sociology and Anthropology Bentley Annex Ohio University Athens, Ohio 45701
On Wed, 2005-10-26 at 11:13 -0400, steven l. rubenstein wrote:
Half the time I click on "Save Page" the next screen is a "Preview" (and my edits are not yet saved). I have been careful about this, and am definitely clicking on "Save Page," not "Show Preview." And this is happening a lot.
Is this happening to anyone else, or is it just me?
Does anyone have any idea why it is happening?
This has happened to me on Commons, but never on en. It is odd. On Commons it seems to happen consistently when I create a new category from a category redlink. I think. You could try filing a bug report as I think there actually is a bug. Any special circumstances or repeatability in your case?
Justinc
steven l. rubenstein wrote:
Half the time I click on "Save Page" the next screen is a "Preview" (and my edits are not yet saved).
I think the main problem here is that there explicitly exists a code path that allows for a preview to be generated even if we know full well that "Save" was clicked, not "Preview". Supposedly there are some situations in which the preview is legitimately supposed to appear even when the user clicked "Save"; the problem is that these situations are either not well-defined, or their definition is so subtle as to make the behaviour unpredictable for end-users, effectively rendering it a bug.
I think not only the easiest but also the best solution to the problem would be to just kill that code path and always save if Save was clicked, even if it means saving it under an IP when the user thought they were logged in.
Maybe there are good reasons for the behaviour that I don't know, in which case maybe it would make sense to sit down and formalise the expected behaviour and then re-design the relevant code logic.
Timwi
Timwi wrote:
steven l. rubenstein wrote:
Half the time I click on "Save Page" the next screen is a "Preview" (and my edits are not yet saved).
I think the main problem here is that there explicitly exists a code path that allows for a preview to be generated even if we know full well that "Save" was clicked, not "Preview". Supposedly there are some situations in which the preview is legitimately supposed to appear even when the user clicked "Save"; the problem is that these situations are either not well-defined, or their definition is so subtle as to make the behaviour unpredictable for end-users, effectively rendering it a bug.
I think not only the easiest but also the best solution to the problem would be to just kill that code path and always save if Save was clicked, even if it means saving it under an IP when the user thought they were logged in.
Maybe there are good reasons for the behaviour that I don't know, in which case maybe it would make sense to sit down and formalise the expected behaviour and then re-design the relevant code logic.
Maybe you should read the many mailing list posts more carefully before you start speculating about the causes and the possible cures. At best we could give a meaningful error message, we can't just make it save.
This bug is associated with a feature which prevents submission of forms by offsite javascript. For example, if a hacker wanted a page deleted, they could write some javascript, put it up on their website, then post a link to it on the user talk page of an administrator. The bug involved makes some unknown random event during an ordinary form submission appear essentially identical to this abuse scenario.
-- Tim Starling
This bug is associated with a feature which prevents submission of forms by offsite javascript. For example, if a hacker wanted a page deleted, they could write some javascript, put it up on their website, then post a link to it on the user talk page of an administrator. The bug involved makes some unknown random event during an ordinary form submission appear essentially identical to this abuse scenario.
-- Tim Starling
So this is what is going on when you get the message "rollback action cancelled to prevent session hijacking"? Always wondered what was going on - if it meant my account might have been compromised (I changed my password after getting that message, just to be safe; always thought I should enquire about what that meant).
Ian
Guettarda wrote:
This bug is associated with a feature which prevents submission of forms by offsite javascript. For example, if a hacker wanted a page deleted, they could write some javascript, put it up on their website, then post a link to it on the user talk page of an administrator. The bug involved makes some unknown random event during an ordinary form submission appear essentially identical to this abuse scenario.
-- Tim Starling
So this is what is going on when you get the message "rollback action cancelled to prevent session hijacking"? Always wondered what was going on - if it meant my account might have been compromised (I changed my password after getting that message, just to be safe; always thought I should enquire about what that meant).
Yes, that's correct.
-- Tim Starling
Half the time I click on "Save Page" the next screen is a "Preview" (and my edits are not yet saved).
This bug is associated with a feature which prevents submission of forms by offsite javascript. For example, if a hacker wanted a page deleted, they could write some javascript, put it up on their website, then post a link to it on the user talk page of an administrator. The bug involved makes some unknown random event during an ordinary form submission appear essentially identical to this abuse scenario.
-- Tim Starling
I had been wondering if this was just subtle encouragement for people to use the preview button more :)