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.
14 years ago
Assignee: general → firefox
Component: Browser-General → General
Product: Browser → Firefox
QA Contact: general → firefox.general
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)
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
Severity: critical → normal
Summary: Apparent lock up when dragging url icon to make a shortcut → 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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
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...
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.
You need to log in before you can comment on or make changes to this bug.