269097 - Dragging a URI icon to the desktop to make a shortcut when the shortcut already exists causes the dialog box to be unreachable without using alt+tab.

Status: RESOLVED INVALID

(Firefox :: Shell Integration, defect)

Description

[N Brooks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When the url icon is drag to desktop, or elsewhere, if a shortcut with the same
name exists, then a dialog pops up with "Overwite yes/n0", BUT it is hidden
behind  FireFox, not brought to top, there is nothing in the task bar, and all
FireFox windows appear locked !

Alt-Tab is the only way to reach it !

Appart from fixing this, you also really need to give a "Rename" option, to save
as a different name, or do an auto-rename, as is done with downloads of the same
file (quite neat - but an option of a warning would be nice)

Also, when the window is full screen, saving shortcuts is a pain - can you not
provide a "Save Shortcut to current page" either on the right-click/context
menu, or on the File menu ?

Thanks (just downloaded full 1.0 release, but doesn't fix this issue)


Reproducible: Always
Steps to Reproduce:
1. Goto any URL, drag the icon prefix to the url to the desktop, and release -
saves shortcut
2. Repeat this - all Firfox windows now appear to lock up !
3. In fact there is a windows "Overwrite this file" box, but it is hidden behind
Firfox
4. Must use Alt-Tab to get to it.
5. There is not even a rename option, either overwrite, or don't save !




Anyone not a serious windows user is going to think that Firefox has died - it
took me a while to realise what had happened the first time.

Comment 1

[s]

While attempting to save any file using the save/save-as dialog boxes, if you
try to click on a shortcut to a folder, the shortcut is percieved by the browser
as a file and then thinks you want to save the file as "folder.lnk", for example. 

This is profoundly inconvenient because the default location for saving is
generally the personal folder, so users often put shortcuts to other frequently
used folders in the personal folder.

This bug does not occur in Firefox 1.0 (english).

I am running the german winxp (sp2)

Comment 2

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050325
Firefox/1.0+

Trying to reproduce in the latest nightly trunk following the reporter's
description and steps for reproduction garners me a dialog brought to focus over
the current Firefox instance, which can't be clicked around and requires
attention, requesting a yes/yesall/no/cancel/ response.  I tried to reproduce
again, following the same steps, and this time, the dialog was brought to the
top, but was out-of-focus (titlebar grayed out) and I had to alt tab through to
close the dialog.  Trying to reproduce a third time garnered the same results as
the first time.

I spoke with asqueella some in IRC, and I took a second glance to make sure this
wasn't an OS issue.  It appears it may very well be something handled by the OS,
but I am not going to mark this Invalid, because I feel that due to the nature
of the confusion for the user when dealing with this issue, it is important for
us to come up with some sort of workaround on Windows systems so that something
can happen to prevent the need to alt tab to get to the dialog box.  I am going
to go ahead and whip up a cleaned up steps to reproduce and expected results and
see what somebody else thinks of this.  Not going to confirm right now.


Steps to Reproduce:
1. Hit the 'Restore Down' button so your window is not maximized
2. Drag the URL icon from the location bar to the desktop
3. Repeat step 2.
4. Alt Tab to get to the dialog.

Actual Results:

User required to alt tab to get to the dialog, the browser is locked until the
dialog is reached and addressed.

Expected Results:

Dialog should have focus the moment it comes up.




Changing the summary to be more descriptive.
Changing severity to normal.
Changing component to OS Integration
CCing Myself

Comment 3

[Tristor]

I solicited a third and fourth opinion, and I am going to go ahead and mark this
invalid.  It /is/ an OS issue and therefore not our deal.  Hmmz, still sucks.

Comment 4

[N Brooks]

Effect is still there in V 1.0.1

The Confirm Replace dialog comes up BEHIND EVERY other open window (backmost),
focus appears to be completely lost (no window, or the desktop or taskbar has
it), all windows are displayed in their inactive state.  The FF window is frozen
- after ALT-Tabbing to the dialog to 'front' it, moving the dialog around leaves
grey areas on the FF window ( see www.nigelbrooks.com/ffbug1.gif for e.g.). 
Fronting other windows then minimisung them similarly leaves the FF window not
redrawn.

However, it DOES appear to be an 'OS' issue, as trying the same thing with
NetScape 8 Beta and IE 6 the same effect is observed.

It would be nice to think that the FF programmers could bypass this OS bug...I
code in C/C++ and would never managed to write a program that freezes its main
window while a modal dialog is present...

Comment 5

[Tristor]

I am not sure if a workaround is possible, but as far as I have been told by
more senior QA people, this isn't something we can/will fix, as it is the
problem of the operating system.  Sorry I can't be more helpful.