Last modified: 2011-03-13 18:05:59 UTC
1. Open any page, click edit 2. Don't change anything, and click Show changes 3. Still don't change anything, try to close the page Now, the text is not touched at all, but EditWarning tells me that I changed something and asks me whether I want to discard changes.
I didn't check whether this happens if a non-ajax preview is used.
(In reply to comment #1) > I didn't check whether this happens if a non-ajax preview is used. It does, and this is deliberate. In Preview or Changes mode, we can't tell if you have made any changes before hitting Preview or Changes, so we err on the side of caution and assume you have. In our usability test in October, we noticed that multiple subjects would change things in the edit box, hit Preview, then not notice that the edit box was below the preview (because the preview was multiple screenfuls long) and click the Edit button, causing them to go to a fresh edit page and lose their changes. EditWarning didn't fire because they hadn't changed anything since the page loaded. For this reason, we added some logic that makes sure EditWarning always fires on preview/changes pages, even if it hasn't detected any changes. Yes, this potentially yields false positives, but 1) clicking preview/changes without having made any changes is kinda pointless and 2) we already have code for AJAXifying the preview and changes views, making this issue moot.
Add another hidden field where original text (from database) or its hash (to reduce page size) is stored, and compare text in the hidden field and wpTextbox1. Trigger a warning if they don't match.
(In reply to comment #3) > Add another hidden field where original text (from database) or its hash (to > reduce page size) is stored, and compare text in the hidden field and > wpTextbox1. Trigger a warning if they don't match. That would pretty much double the size of the edit page HTML for large articles, for a very small gain. Also, the dialog says MAY be lost (not WILL be lost; if you use e.g. Firefox, you also don't lose your changes immediately upon navigating away), the use case for this bug is marginal and pretty much pointless, and this'll be moot when preview and changes use AJAX, which is not far away.
Is a hash really so expensive?
(In reply to comment #5) > Is a hash really so expensive? Ah, I overlooked that part of Liangent's response, sorry about that. Including a hash of the page content is not expensive, true, but JavaScript has no native hashing functions, so we couldn't really use it.
(In reply to comment #4) > Also, the dialog says MAY be lost (not WILL be > lost; if you use e.g. Firefox, you also don't lose your changes immediately > upon navigating away), The meaning of 'may' is missing in its Chinese translation: "离开这个页面会令您遗失之前的所有更改。"?
(In reply to comment #7) > (In reply to comment #4) > > Also, the dialog says MAY be lost (not WILL be > > lost; if you use e.g. Firefox, you also don't lose your changes immediately > > upon navigating away), > > The meaning of 'may' is missing in its Chinese translation: > "离开这个页面会令您遗失之前的所有更改。"? That can be handled on TranslateWiki.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #4) > > > Also, the dialog says MAY be lost (not WILL be > > > lost; if you use e.g. Firefox, you also don't lose your changes immediately > > > upon navigating away), > > > > The meaning of 'may' is missing in its Chinese translation: > > "离开这个页面会令您遗失之前的所有更改。"? > That can be handled on TranslateWiki. And I've already fixed it.
