[wasn't sure where this belonged, pls reassign thanks] Build ID: 2000042708 Current behavior is the same as IE's, but not NS 4.x...the link contained by the file icon (next to the URL bar) drag operation is whatever's in the URL bar at the time, rather than the URL of the current loaded page (regardless of what the URL bar displays). I noticed this when I was refuting someone's claim that there was no way to go to a certain URL after cut and pasting it into the URL bar (I argued that there was because after pasting, you could drag the file icon into the content area to go there). At first I thought that this "new" behavior (to NS, anyways) was good for the very reason stated above - no keyboard input is essentially required to go to an URL, thus in some way getting rid of the absolute need for a Go button. However, upon rethinking this, I'm not quite so sure. After all, accidentally typing in the URL bar and then later on dragging the icon to bookmarks would cause a bookmark with the wrong URL to be produced; this would be the same situation when dragging the icon to an external program or to the desktop as a shortcut (if we ever get that working). This could be potentially confusing for old NS users who aren't adapted to the new system (icon = what's in URL bar rather than the page that's loaded). This new way has both pros and cons; I'm wondering if it was by design (intentional), or is meant to work in the same way as NS 4.x What do you think?

forgot to finish summary, updating...

I dunno...I mean the bookmark icon is right beside the URL bar so if you drag from it you would expect that you were dragging what was in the URL bar, not the current page.

I know what you mean; I expect this to be marked wontfix, but I wanted to bring it up anyways just to ensure that the system was changed from 4.x on purpose 4xp (if this wasn't intentional)

User Interface: Design Feedback, I think :-) Gerv

Reassigning to German

ben, is you or slamm working on this? I know it will be fixed as N4.x later, but not sure who is doing it. If I am wrong, then give this bug to don and re-assign or kill it.

this came up in bug 36788.

As far as the user is concerned, the proxy icon represents the currently-loaded page. So I think when dragged, it should really create a bookmark/shortcut/link/whatever to the currently-loaded page -- not to whatever happens to be in the location bar at the time. Otherwise you could easily create bookmarks/shortcuts/links/whatever to invalid addresses, if you had mangled the contents of the location bar. (For going to a copied location entirely with the mouse, you probably want a `Paste and Go' item in the context menu for the location bar.)

on the other hand with your scheme you could create a link to the *wrong page* (by dragging this URL icon thingy and thinking it was the same as what was in the URL bar but it was actually what the currently loaded page). I strongly object to this because the url icon thingy is right up there beside the URL bar so people are bound to think that it produces a shortcut to the thing in the URL bar. How about this for an idea, in the context menu (the one you get by right clicking, or control clicking or whatever) have an item called "create shortcut". When you click on this you can drag a shortcut off the menu (the same way as you can drag a shortcut off the url bar currently), except the shortcut you get this time is to the current page. This would make much more sense to me since you then click on the page to get a shortcut to the page, or you click on the URL bar to get a shortcut to the url. I don't even know if this could be done, but I think this would be incredibly cool, imagine a first time user bringing up the context menu and seeing "create shortcut". He clicks on it, the menu disappears and he is left holding a little shortcut icon which he can then drag to the desktop. Food for thought.

Sounds a bit hairy to me -- it would be inconsistent with every other drag-and-drop action I know of, where you have to have the mouse down while you are dragging. Your suggestion would be the equivalent of having something glued to your hand. Perhaps a better idea is for clicking on the proxy icon to automatically restore the contents of the location bar to the address of the current document. What is the real address of this page? Click on the proxy icon ... Ah, there it is. That way you'd always be dragging the same address as was shown in the location bar.

>Sounds a bit hairy to me -- it would be inconsistent with every other >drag-and-drop action I know of, where you have to have the mouse down while you >are dragging. Your suggestion would be the equivalent of having something glued >to your hand. >That's not really what I meant though :). What I meant was that when you click >on the "create shortcut" menu item (*before* you release the button), the menu >goes away and you (the user) is left holding the url icon to be dragged >wherever you want. That way there is no inconsistency, since you would be >holding the mouse down while you drag it. Hate to disagree with you here, the way I see it the whole purpose of the url icon (proxy icon whatever :) ) is to provide a convenient spot to click on to create a draggable shortcut. If you really wanted this behaviour then wouldn't it be better to create a button to produce this effect? Perhaps a better idea is for clicking on the proxy icon to automatically restore the contents of the location bar to the address of the current document. What is the real address of this page? Click on the proxy icon ... Ah, there it is. That way you'd always be dragging the same address as was shown in the location bar.

So, would starting to drag the URL icon count as "clicking" it and restore the URL to the page URL? Side note: I asked that the escape key revert the URL in 32194. Having both pressing escape and clicking the URL icon revert the URL would be nice because it would allow both keyboard-only and mouse-only people to be happy.

Gwyn - that would be pretty cool, but as Matthew said, it goes against every drag-and-drop convention I've seen. Matthew's idea does work pretty well, but I can perhaps see instances where people accidentally click on the icon after typing in a long address, not expecting it to restore the URL bar to the loaded address (granted, this wouldn't happen too often). Or how about a tooltip that popups when the mouse is over the icon (perhaps with a shorter delay than the others) with the address of the loaded page, so people would know where the icon's linking to? I still can't imagine too many instances where people would go to the trouble of typing an address into the URL bar _just_ for the purpose of dragging the icon to create a shortcut/bookmark, with no real desire of going to the page. Most of our users will likely be used to the NS 4 way of doing things, and I vote for keeping it that way. Another thought is to have a system like IE's (I just now realized how it functioned). IE 5.5 keeps the file icon visible until the second the user changes the text of the address bar from the loaded URL, at which point the icon becomes invisible. Although, the space where the icon had been is still draggable, but dragging it does nothing (I disagree with this design - if there's nothing there you shouldn't be able to drag it). Thus, they keep a system like NS 4.x's, but help avoid confusion by simply making the icon disappear altogether once the user voluntarily changes the text in the URL bar.

Reassigning for Don.

Move to M21 target milestone.

Waitasec. 4xp behavior is for dragging to use the TITLE of the current page (no matter what is in the location bar), not the URL. Which makes a whole lot more sense, really.

That's true, but that's really a separate bug. The icon still needs to carry an URL whether it displays it or not when dropped, and as this bug mentions, the URL that it carries is the URL in the URL bar rather than the loaded page address.

So, we need a decision on this.

Well, pending a final decision by German, I'd recommend doing what IE does -- hiding the proxy icon whenever the contents of the address field is not the same as the current URL. That would seem to make the most sense.

*** Bug 47590 has been marked as a duplicate of this bug. ***

German inadvertently agreed with me (bug 47590). Updating.

nav triage team: nsbeta3-

renominating - when we in triage team marked this -, we did not understand. Apparently, when you drag a proxy into bookmarks, you do get a bookmark. When you later click that bookmark, the content page shows a picture of the proxy icon - not any web page. (The URL saved is the local file address for the proxy icon.) recommend nsbeta3+ to either fix the proxy behavior or remove the proxy entirely (another more minor proxy problem is bug 47590).

Maybe for the interim if we do not get it to work right (and since draggin and dropping does not work so well at times) we should take the proxy icon out completely and put it back in once we are confident it will work as intended.

nav triage team: 3+, P1

I don't think hiding and the icon is a good idea (instability in the UI). I suggest dimming it instead of hiding.

To clarify, nav triage team gave a plus to either fix this problem or remove the proxy completely. Note the more serious proxy problem at bug ??? (german - it was on your list) where dragging a proxy into bookmarks created a bookmark that, if later clicked, would load into the content area the proxy icon itself, no web page at all.

PDT tried johng's steps from 8/24 and couldn't reproduce. We don't think the original description is an nsbeta3+. Marking P5 based on original description.

nav triage team: nsbeta3- claudius: I can btw repro this w/2000091408 builds

Mass moving all Navigator bugs to the Nav team.

nominating for nsbeta1 To recap whats needed here is "...hiding the proxy icon whenever the contents of the address field is not the same as the current URL..."(mpt)

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

i think this should be an nsbeta1-.

-> Joe, who has this partly working.

fixed