http://bugs.winehq.org/show_bug.cgi?id=24324
Summary: Firefox 4.0 Beta 5 doesn't allow toolbar customization Product: Wine Version: 1.3.2 Platform: x86-64 URL: http://www.mozilla.com/en-US/firefox/all-beta.html OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: RandomAccountName@mail.com
Created an attachment (id=30654) --> (http://bugs.winehq.org/attachment.cgi?id=30654) terminal output
To reproduce, go to view -> toolbars -> customize. On Windows, this makes it possible to drag-and-drop the objects from the window that pops up, as well as the new tab button, navigation buttons, etc. to a different location on one of the toolbars. For example, you can move the new tab button to the left side of the tab bar. On Wine, it just shows an "action not allowed" cursor when attempting this, and nothing happens.
http://bugs.winehq.org/show_bug.cgi?id=24324
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=24324
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #1 from André H. nerv@dawncrow.de 2010-09-09 13:16:11 CDT --- for me it works, i have 32-bit firefox 4 beta 5 running in a wow64 prefix with Windowsversion set to Win7.
http://bugs.winehq.org/show_bug.cgi?id=24324
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Firefox 4.0 Beta 5 doesn't |Firefox 4.0 Beta 5 |allow toolbar customization |sometimes doesn't allow | |toolbar customization
--- Comment #2 from A Wine user RandomAccountName@mail.com 2010-09-09 13:45:29 CDT --- (In reply to comment #1)
for me it works, i have 32-bit firefox 4 beta 5 running in a wow64 prefix with Windowsversion set to Win7.
After some more testing, it doesn't seem to happen every time. I haven't seen the behavior change in a single wineprefix, though. Some work, some don't, although they were all created and used the same way. BTW, I'm using 32-bit prefixes.
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #3 from A Wine user RandomAccountName@mail.com 2010-09-09 14:00:11 CDT --- I can't seem to reproduce this at all with wineprefixes stored on ext4 - my earlier attempts were on tmpfs.
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #4 from André H. nerv@dawncrow.de 2010-09-09 14:38:11 CDT --- ext* is preferred by wine i think. there should be some comments in the readme
http://bugs.winehq.org/show_bug.cgi?id=24324
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED Summary|Firefox 4.0 Beta 5 |Firefox 4.0 Beta 5 |sometimes doesn't allow |sometimes doesn't allow |toolbar customization |toolbar customization on | |tmpfs
--- Comment #5 from A Wine user RandomAccountName@mail.com 2010-09-12 09:28:16 CDT --- (In reply to comment #4)
ext* is preferred by wine i think. there should be some comments in the readme
The readme says "using a native Linux file system such as ext3 is recommended." Tmpfs is a native Linux file system, right? But on the other hand, I hadn't noticed when I filed this bug that C: is detected as a RAM drive when tmpfs is used. I don't think it's possible to install Windows on a RAM drive, at least without dedicated hardware. Since I can't test what Windows does with the same setup, perhaps it's best to abandon this bug...
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #6 from Vincent Povirk madewokherd@gmail.com 2010-09-12 10:21:46 CDT --- If Windows can't be installed on a RAM drive, then we probably should never report C: as a RAM drive.
http://bugs.winehq.org/show_bug.cgi?id=24324
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|ABANDONED |
--- Comment #7 from André H. nerv@dawncrow.de 2010-09-12 10:23:52 CDT --- just thought so too, looking at the code at ntdll and winecfg right now. i'll atach a patch when ready, so you might want to test it.
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #8 from André H. nerv@dawncrow.de 2010-09-12 11:17:06 CDT --- in the functions detecting if its a ramdisk it is hard to detect if they are actually detecting c:
i created a tmpfs mount in /media and chowned it to me, and it seems to work fine with firefox 4b5 and it's toolbar customization without any patching... i created it with: cd /media sudo mkdir bla sudo mount -t tmpfs -o size=500M,nr_inodes=5k,mode=0777 tmpfs bla cd .. sudo chown myusername bla
and used it like WINEPREFIX=/media/bla wine firefox_setup.exe
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #9 from A Wine user RandomAccountName@mail.com 2010-09-12 11:48:09 CDT --- I just noticed something else strange going on here aside from drive type detection. This is what I just did:
mkdir ~/.wine sudo mount -t tmpfs tmpfs /home/me/.wine -o uid=1000 ~/wine-git/wine "Firefox Setup 4.0 Beta 5.exe" <- works rm -rf ~/.wine/* ~/wine-git/wine "Firefox Setup 4.0 Beta 5.exe" <- creates a broken prefix and doesn't allow toolbar customization
The broken prefix only contains the following files (until I install something, anyway): ./system.reg and user.reg ./dosdevices/c: and z: ./drive_c/windows/win.ini ./drive_c/windows/system32 <- empty folder
Does this procedure look correct to you, or am I doing something here to break the second wineprefix creation?
http://bugs.winehq.org/show_bug.cgi?id=24324
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |programs Ever Confirmed|0 |1
--- Comment #10 from André H. nerv@dawncrow.de 2010-09-13 12:50:15 CDT --- I can reproduce that here, so confirming. I am not sure how wineboot detects if it should create/update the prefix, i guess that is the main problem which should be fixed, even if you are really doing crazy things :)
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2010-09-13 14:54:36 CDT --- (In reply to comment #9)
I just noticed something else strange going on here aside from drive type detection. This is what I just did:
mkdir ~/.wine sudo mount -t tmpfs tmpfs /home/me/.wine -o uid=1000 ~/wine-git/wine "Firefox Setup 4.0 Beta 5.exe" <- works rm -rf ~/.wine/* ~/wine-git/wine "Firefox Setup 4.0 Beta 5.exe" <- creates a broken prefix and doesn't allow toolbar customization
The broken prefix only contains the following files (until I install something, anyway): ./system.reg and user.reg ./dosdevices/c: and z: ./drive_c/windows/win.ini ./drive_c/windows/system32 <- empty folder
Does this procedure look correct to you, or am I doing something here to break the second wineprefix creation?
You are breaking it, the correct way to remove it is rm -rf .wine, not rm -rf .wine/*.
http://bugs.winehq.org/show_bug.cgi?id=24324
--- Comment #12 from A Wine user RandomAccountName@mail.com 2010-09-14 08:56:42 CDT --- (In reply to comment #11)
You are breaking it, the correct way to remove it is rm -rf .wine, not rm -rf .wine/*.
I can't do that when a file system is mounted at .wine:
rm -rf ~/.wine rm: cannot remove directory `/home/me/.wine': Device or resource busy
I'd have to umount tmpfs, remove the directory, recreate the directory, and remount tmpfs every time I want to make a fresh tmpfs-hosted prefix. That, or set WINEPREFIX to use a directory within my tmpfs file system instead of the root. I guess it isn't really a big deal, just less convenient that way.
http://bugs.winehq.org/show_bug.cgi?id=24324
Spammer spammis@spam.la changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spammis@spam.la
--- Comment #13 from Spammer spammis@spam.la 2011-06-03 16:25:32 CDT --- (In reply to comment #12)
(In reply to comment #11)
You are breaking it, the correct way to remove it is rm -rf .wine, not rm -rf .wine/*.
I can't do that when a file system is mounted at .wine:
rm -rf ~/.wine rm: cannot remove directory `/home/me/.wine': Device or resource busy
My Wine prefixes have a file called ~/.wine/.update-timestamp. If you use "rm -rf ~/.wine/*", the .update-timestamp file won't be deleted because it begins with a dot. Is the file .update-timestamp causing a problem here? I'm not sure what the file does. Would "rm -rf ~/.wine/* ~/.wine/.update-timestamp" have the same result?
http://bugs.winehq.org/show_bug.cgi?id=24324
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #14 from André H. nerv@dawncrow.de 2011-06-23 06:52:09 CDT --- This bug is invalid
http://bugs.winehq.org/show_bug.cgi?id=24324
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com 2011-07-07 16:15:18 CDT --- Closing.
-
wine-bugs＠winehq.org