Closed
Bug 346471
Opened 18 years ago
Closed 17 years ago
Undo in location bar causes strange results after navigating
Categories
(Camino Graveyard :: Location Bar & Autocomplete, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino1.6
People
(Reporter: trevor, Assigned: mark)
Details
(Keywords: fixed1.8.1.12)
Attachments
(1 file)
(deleted),
patch
|
bugzilla-graveyard
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060728 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060728 Camino/1.0+
Changes to the location bar in Camino are added to the undo chain. However, navigating to another page is not. Therefore, pressing undo after navigating to another page (or if the contents of the location bar is transformed in any way) causes strange results.
Reproducible: Always
Steps to Reproduce:
1. Open a browser window.
2. Enter "mozilla.org" into the location bar and press enter.
2. Enter "caminobrowser.org" into the location bar and press enter. The location bar will change to "http://caminobrowser.org/"
3. Click in the location bar and press undo.
Actual Results:
The address changes to "http://www.mozilla.org/browser.org/".
Expected Results:
Camino should either not allow me to undo after navigating or make a sane decision as to what the location bar should be after undo.
Comment 1•18 years ago
|
||
Undo behaviour in this case is also going to have to take into account whatever sort of session saving/tab undo we implement.
If a keypress results in browser activity (rather than simply an edit to the location bar), Undo should function like Back, or simply not do anything (if functioning like Back doesn't make sense). If the keypress does not result in browser activity, Undo should undo the typing.
cl
Comment 2•18 years ago
|
||
BTW, Safari's behaviour is what's proposed here -- if typing results in navigation, Undo does nothing. If typing does not result in navigation, Undo un-does the typing.
Confirming and targeting for 1.2. I might take a look at this soon-ish.
Assignee: nobody → bugzilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.2
In other words, navigating clears the location bar's Undo buffer?
Comment 4•18 years ago
|
||
(In reply to comment #3)
> In other words, navigating clears the location bar's Undo buffer?
Yeah, that's what's being proposed.
cl
Updated•18 years ago
|
Target Milestone: Camino1.6 → ---
Assignee | ||
Comment 5•17 years ago
|
||
Gross. I noticed this while testing a fix for bug 409634.
Assignee | ||
Comment 6•17 years ago
|
||
-[AutoCompleteTextField setURI:] isn't telling the undo stack about the changes it's making in the "not currently editing" case. The state of the text field is out of sync with what the undo stack thinks, so undo operations don't have the expected effect.
Assignee | ||
Comment 7•17 years ago
|
||
Actually, our code already tries to purge the undo stack of actions that affect the location bar once editing is done, but it's ineffective because of a bug elsewhere. Here's where we try to take the text field edits off of the undo stack:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/camino/src/browser/AutoCompleteTextField.mm&rev=1.56&mark=1139-1140#1136
The field editor for the location bar is an AutoCompleteTextFieldEditor (NSTextView subclass), defined in BrowserWindowController.mm. It maintains its own NSUndoManager instance that BrowserWindowController makes the window's active undo manager while the text field is first responder. The bug is that AutoCompleteTextFieldEditor makes its own NSUndoManager available through a selector named undoManagerForTextView:, which is actually an NSTextView *delegate* method - an NSTextView should *call* this, not *implement* it. An NSView (super-superclass of NSTextView) is supposed to make its NSUndoManager available at the undoManager selector. Thanks, David Haas.
What happened was that the code above would look for its undo manager using the standard mechanism but wind up getting the window's undo manager, which was wrong, because that wasn't the undo manager that got the text editing events pushed ont it and it wasn't the undo manager that was hooked up to the edit menu and command-Z while editing. There would be nothing relevant to remove from the window's undo manager, and the next time the field was edited, it would bring along its own undo manager again, prepopulated with changes from the previous edit, which didn't make any sense given that the field's contents likely changed since the last time it was edited due to things like navigation and adding "http://".
The fact that you could undo across editing sessions in the location bar was an unintended misfeature, and a buggy one at that. Let's kill it!
Assignee | ||
Comment 8•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Attachment #294461 -
Flags: review? → review?(cl-bugs)
Comment 9•17 years ago
|
||
Comment on attachment 294461 [details] [diff] [review]
Implement the correct selector, don't allow undo across location bar editing sessions
code r=me, but I can't test at the moment.
Attachment #294461 -
Flags: review?(cl-bugs) → review+
Assignee | ||
Comment 10•17 years ago
|
||
Checked in on the trunk and MOZILLA_1_8_BRANCH for 1.6b1:
trunk/mozilla/camino/src/browser/AutoCompleteTextField.mm 1.59
trunk/mozilla/camino/src/browser/BrowserWindowController.mm 1.349
1.8/mozilla/camino/src/browser/AutoCompleteTextField.mm 1.37.2.22
1.8/mozilla/camino/src/browser/BrowserWindowController.mm 1.201.2.144
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
Target Milestone: --- → Camino1.6
You need to log in
before you can comment on or make changes to this bug.
Description
•