User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050920 Camino/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050920 Camino/1.0+ If you switch tabs while autocomplete has suggestions open, they should collapse. Reproducible: Always Steps to Reproduce: 1. Make a tab, and load a page in it 2. Make a new tab, and type "www.appl", invoking the autocomplete 3. Switch to the previous tab Actual Results: The autocomplete options are still available Expected Results: collapse the autocomplete options
Hrm. The way we do this right now is by looking to see if the focus has been removed from the location bar, and if it has, we collapse the popup. The focus is retained in the location bar when switching tabs. This seems to me like the most logical behaviour for the focus. The problem arises because we look for an onBlur event in the location bar. Is there any (efficient) way to tell if the location bar still has focus, but the active tab has changed? That's probably the only way this is going to happen. cl
(In reply to comment #1) > The focus is retained in the location bar when switching tabs. This seems to me > like the most logical behaviour for the focus. Is it really, though? For instance, If you type in a new tab, then switch back to this tab right now, you'll still have the "encrypted yellow" in the location bar, but the text in the location bar has nothing to do with a secure URL. It seems to me that since we only have one location bar and multiple tabs, the location bar should always represent the active tab.
The problem with that approach is it would do all sorts of nasty things to the text in the location bar while the focus is still there. If the focus is in a text field, I expect that text field to retain what I type and to respond to my typing commands. What you're proposing (if I'm understanding you properly) would effectively change the contents of the location bar to match the active tab, which seems to me like it would lead to massive confusion on the part of the end user. Our current system, which matches that used by Safari, allows the user to switch to any open tab after beginning the typing in the location bar, press return/enter, and load the URL in that tab. Firefox does things a different way: it associates each tab with its own copy of the location bar. Bear in mind that Firefox uses non-native controls, which (probably) makes this a lot easier to implement. Camino uses native OS X controls where possible, and I sort of doubt this is critical enough that we should be worrying a whole lot about writing a custom control to provide this feature enhancement. cl
(In reply to comment #3) If the focus is in a > text field, I expect that text field to retain what I type and to respond to my > typing commands. Exactly -- if I load the same web page form in two tabs, type in one textbox, switch tabs, type something different in the other textbox, and switch back, I expect to see what I originally started typing in page 1. When I switch to tab 2, I should see what I'm typing in textbox 2. This model will hold whether or not I'm done entering the text (i.e., have typed and loaded the URL or have typed a portion of a URL). The location field does not follow this paradigm. > Camino uses native OS X controls where possible, and I sort of doubt this is > critical enough that we should be worrying a whole lot about writing a custom > control to provide this feature enhancement. This doesn't require a custom control. The location bar text changes all the time when you change tabs -- if the pages are loaded, the text in the location bar changes to reflect the URL of the current tab. The only time it refuses to change is if you're entering text. I don't think Camino should distinguish between "typed text" and "text currently being typed" in terms of whether that sticks in the location bar during tab changes. Instead, each tab should simply have its current location bar string, and whenever that tab becomes active that string should be shown in the location bar. This appears to be the simplest and most consistent human interface choice. It also doesn't require any sort of custom control.
WONTFIX, per IRC. bug 348494 is a much more reasonable solution, and covers comment 2.