Closed Bug 473467 Opened 11 years ago Closed 11 years ago
File picker dialog sometimes doesn't close when Open/Save/Cancel is clicked
This is a spinoff from bug 420967 and is probably also known as 426363. From me: > For STR, just try to pick a file to attach to bugzilla a few dozen times. > You'll hit this eventually; the OK button just won't do anything until > you drag the window or click outside the dialog. From Henrik: > Meanwhile I'm getting annoyed by this bug in the > latest nightly builds. It occurs very often in the "save as" dialog. Pressing > Save several times does sometimes nothing. Clicking outside of the dialog > executes the action instead. You don't have to complete the bugzilla attachment process; merely clicking the Browse button, picking a file, and clicking Open over and over will cause this bug to appear.
Something else is involved other than just the browse button.. not sure if the browser has to be busy or something as well maybe.
Ok, now this is ringing a bell for me. I think I have hit this bug when I was uploading pictures to picasaweb.google.com. I was just able to reproduce it quite easily using these STR: 1. Visit picasaweb.google.com 2. Try to upload a photo to an album 3. Select browse, then select the image you want 4. Press the Open button Nothing happens. If you press it enough times, it sometimes will finally show the file and the file picker will vanish. I am running on a Mac using the latest 1.9.1 nightly.
(In reply to comment #2) > it sometimes will finally show the file Yeah, this part is actually quite weird -- happens even if you do the window title drag or whatever. It looks like you started dragging a file from the filepicker (drag&drop drag) and then reset the drag, so you get the little animation of the file sliding/fading back to where it came from.
Further folders you have opened by double clicking inside this file picker dialog are shown as empty. I have to go back and open the folder again to see the containing files and folders.
I can't reproduce any of this. (Though I didn't try Marcia's STR, because it'd be a lot of trouble to set myself up for it.) There's clearly something missing from these descriptions ... but, not having seen this problem myself, it's very difficult for me to figure out what. We need much better STR to be able to block on this ... or to have a chance to fix it.
Obligatory question -- do these problems go away in Safe Mode?
Happens for me in safe mode too (and certainly in a profile with no extensions). The problem is that it's not reliably reproducible. :( Sometimes it seems like using Cmd-Shift-G to go into my .hg/patches folder makes this more likely to trigger, but maybe that's just because I do that for most of my attachments.
Ah, I think I have some additional info -- I think it's drag & drop related. If you can somehow initiate a drag with something not agreeing that a drag got initiated with a file from the dialog, then you get into this state. This explains the drag cancelled animations that are seen. I still can't come up with a 100% STR, but I don't think you'll get one, unfortunately. It's an intermittent problem. Dragging the mouse a lot with the mouse button held down in the dialog might help to reproduce it.
> If you can somehow initiate a drag with something not agreeing that a drag got > initiated with a file from the dialog, then you get into this state. Please unpack this :-) Or at least give me some idea how to do it.
Basically lots of clicking and dragging. It's a very unformed idea right now. My thinking is that some code somewhere thinks that a drag started or is supposed to start, and hasn't ended, even though the mouse button has been released. So that code is still in drag mode. When you click the Open button in this state, it stops pulsing, but the dialog doesn't close (presumably because you're in drag mode still, but the button ate the click). When you do something else that doesn't explicitly handle mouse buttons, the drag code sees it, cancels the drag, which ends up allowing the dialog to close. That explanation is consistent with the behaviour that I observe. I don't know whether I'm talking about apple's drag code or our drag code, though.
For what it's worth, the Open File and Save As dialogs are Apple dialogs -- Cocoa app-modal dialogs. So (in principle) it should be possible to see the same kinds of problems in, say, Safari.
Could it be that something odd is happening just *before* the Open File or Save As dialog opens, or while it's opening?
Wild guess -- try my patch for bug 468393 and see if this makes any difference. There's a tryserver build in bug 468393 comment #24.
Steven: Would it help to be looking in the Console when we are hitting this issue? I am just wondering where the integration touch point would be that might give us some more clues?
I notice this fairly frequently as well. I've noticed that it sometimes causes some of my Finder "favorites" (in the sidebar) to disappear, so it might be related to it thinking I've started a drag for them when I try to select them (dragging them off the sidebar is one way to remove them, I think). Clicking the window's title bar usually causes it to get unstuck, and then I see the poof of smoke icon and the window just disappears (sometimes with the right file ending up in the <input type="file">, sometimes not).
(In reply to comment #14) If there's anything in the Console, that might help. But I don't expect there'll be anything.
> I've noticed that it sometimes causes some of my Finder "favorites" (in the > sidebar) to disappear Oh! I was wondering why my Desktop and home dir had disappeared from there at some point! So I usually start by clicking on my home dir in the sidebar, then click on the "mozilla" dir, then the tree I want, then Cmd-Shift-G to go to .hg then click on patches and then on the patch I want. Alternately, I click on my home dir in the sidebar, then upload directly from there. I pretty much always start with the sidebar click.
Hrm. No idea if it's related, but I just noticed: 1/14/09 2:15:42 PM firefox-bin error in CoreDragDispose: -1850 1/14/09 2:15:42 PM [0x0-0x1b01b].org.mozilla.firefox 2009-01-14 14:15:42.621 firefox-bin[567:10b] error in CoreDragDispose: -1850 in my console. I'm pretty sure I've only been able to reproduce the bug once since my last restart.
(In reply to comment #18) Interesting. This error must have happened while in one of Apple's Cocoa app-modal dialogs, rather than in browser code -- if it'd happened in browser code, the browser would have crashed with an Objective-C exception crash.
> the browser would have crashed with an Objective-C exception crash. Or (if the browser didn't crash) the error message would have contained the following string -- "Mozilla has caught an Obj-C exception".
I ran the Tryserver build in Comment 13 and still was hitting this bug in my first phase of testing. I went to carbonmade.com and logged in, and then tried to upload some files. The "Open" button was non responsive for the first few attempts, but it seems after I got the first file to finally load then I was able to add four more successfully. It seemed the only way I could upload a file was to switch focus out of the file picker and then back in. No errors in the Console or the Error console.
Sigh. Thanks for the effort, though.
I suspect what triggers this bug is something you do just before (or just as) the Open File dialog opens. Please keep an eye out for this. And, by the way, I've had zero luck reproducing this, despite having spent the last hour at it.
Would be great to fix this bug but until we have better repro steps I don't think we can block FF 3.1. This does not seem to impede regular use of the browser (I use those dialogs all the time) and my understanding is that eventually the button does work. Hopefully we can track this down by the time we ship or at least ship a fix in a software update.
Priority: -- → P1
"my understanding is that eventually the button does work" Sorry, I meant to say that there is a way to get out of the situation, it doesn't require something drastic like a browser restart.
I'll be honest, it impedes the crap out of my experience. :) I can reproduce this reasonably consistently by launching a file picker, choosing one of the file system shortcuts in the left sidebar (e.g. "Desktop") and then trying to choose a file from a subfolder. Are there things you'd like me to do with my version to get you more information? I suspect others here could do the same?
> Sorry, I meant to say that there is a way to get out of the situation, Though not discoverable. My first time it took me about 10 minutes to get there...
Without good STR, there's nothing that can be done here. So if you want to help, we need what we don't yet have -- precise, detailed STR. We also need people to look for possible bad interactions with other software. It goes without saying that you need to test with extensions disabled. But other software may also be involved. For example see bug 474629 comment #3.
It'd also be interesting to see if similar problems happen with the File Open dialog in Safari.
As mentioned, the STR are tricky, but here you go: http://people.mozilla.org/~johnath/bugstuff/FilePickerBug.swf I can't make that happen in Safari (neither from their file picker sheet, nor from File->Open File) and I also can't get it to happen in Firefox 3.
I see exactly what Johnathan demos in Comment 31. The tricky thing is it does not always happen. I go through periods when it works and does not work. Safari works fine when I upload my pictures to carbonmade or picasaweb and I never seen the stuck button there.
(In reply to comment #31) Thanks! This is exactly the kind of detailed, specific description that I've been looking for. Unfortunately I still haven't been able to get it to "work": When I click between items the highlighting always seems to disappear. This never happens in your demonstration -- do you ever see it? I'm going to keep trying (on different machines and in different OSes). But please do check if you've got LiveType installed (see bug 474629 comment #3). And if you do, see if (temporarily) uninstalling it makes any difference. (By the way, just now I tested on a MacPro running OS X 10.5.6.)
Also, does using a fresh profile make a difference? Maybe there's some setting you're using but I'm not using.
johnath and marcia: This is really important. Please try it! > But please do check if you've got LiveType installed (see bug > 474629 comment #3). And if you do, see if (temporarily) uninstalling > it makes any difference.
No LiveType here.
(In reply to comment #35) > johnath and marcia: > > This is really important. Please try it! > > > But please do check if you've got LiveType installed (see bug > > 474629 comment #3). And if you do, see if (temporarily) uninstalling > > it makes any difference. I don't have final cut, and see no obvious sign of LiveType - how can I be sure?
> I don't have final cut, and see no obvious sign of LiveType - how > can I be sure? I'm not sure myself (since I don't have it and it's not freely available for me to install). But here are a couple of things worth trying: 1) Do 'find . -name LiveType\*' in /System/Library/ and /Library/. 2) Run Firefox in gdb, open the file picker, then break in gdb, do 'info sharedlibrary', and search (in Terminal) for 'LiveType'.
> 1) Do 'find . -name LiveType\*' in /System/Library/ and /Library/. I just did this on my 10.5.6 MacPro and found no matches at all.
Johnathan: If you and Vlad don't have LiveType, we can rule it out has having any involvement here. But I'm still stuck -- though your STR from comment #31 is all I could ask for, I've tried and failed (over the last hour, on three different machines, in OS X 10.4.11 and 10.5.6) to reproduce it even once. So I'm quite sure there are still additional factors we haven't yet uncovered, and I need help from other people (those who can reproduce this bug) to identify them. Please test with a fresh profile. And note that (from the knowledge I have of what happens when an OS-provided Cocoa app-modal dialog runs above Firefox) I suspect that a lot depends on what happens as (just before and after) you click on the Browse button.
Also, it'd be nice to know what kind of computer you're working on, with what kind of mouse, and what OS version.
Macbook pro, trackpad, darwin 9.6.0, Mac 10.5.6 I also have a new video for you. I won't spoil the ending, but the connection to drag and drop is made more apparent! http://people.mozilla.org/~johnath/bugstuff/MoreFilePickerCrazy.swf Also, there's a brief interlude from Jeff trying to reproduce on Mac, but nothing came of it, so feel free to ignore that part. :)
The plot thickens :-) I'll need to watch your video a few more times to be sure I've gotten everything from it. But, on your new evidence, it looks like a mouse-up event is somehow being ignored/misdirected. In this respect it's a lot like bug 474616 (which is very easy to reproduce). But in other respects these two bugs are completely unrelated. Especially when you consider that what's running in the file picker is entirely Apple's code (this is why I keep insisting on the importance of what happens as you press the Browse button, when you're still in browser code). Prior to the patch for bug 419668 (which also fixed bug 420967), mouse events could sometimes still (incorrectly) get through to Gecko when you clicked *outside* the file picker. But even then, I don't believe any of them could be misdirected to Gecko when you clicked *inside* the file picker. However, now that I see a misdirected mouse-up is probably involved, I may be able to come up with a testing patch (not a fix) for you (and others who can repro this) to try. It'd still be *really* nice to hear your results with a fresh profile.
(In reply to comment #43) > It'd still be *really* nice to hear your results with a fresh profile. Sorry, meant to include that in the last one. I believe I've reproduced this on fresh profiles in the past, but trying now I'm having trouble doing so. Given how intermittent it is, that's not TOO surprising, but yeah, no luck yet on a new profile.
I will try as well with a new profile. I am running one now and periodically testing uploading files.
Johnathan: I can easily reproduce your strange drag-that-doesn't-drag (but moves the highlight) trick (the one that also "works" in Safari). But I still can't, for the life of me, reproduce the original bug (or the weird drag artifact while clicking on the file picker titlebar). I tested on my early-model MacBook Pro running OS X 10.5.6. Johnathan and Marcia: I look forward to hearing your results running with a fresh profile.
Looking for patterns: Has this problem only been seen on a laptop?, using a trackpad?, on a MacBook Pro using a trackpad? Or to put this another way, has this problem ever been seen using a mouse, and/or on a desktop? Has this problem been seen in both OS X 10.4.11 and 10.5.6? Or only on OS X 10.5.6?
My setup is the same as the one in comment 42.
(In reply to comment #47) > Or to put this another way, has this problem ever been seen using a > mouse, and/or on a desktop? Yes, external mouse/keyboard from Apple. Happens for me while working on a MB and MBP. > Has this problem been seen in both OS X 10.4.11 and 10.5.6? Or only > on OS X 10.5.6? I don't have 10.4 accessible right now.
I was seeing this in 10.5.5 as well, so it's not tied to the latest OS update.
(Following up comment #47) So it looks like this problem happens with both a trackpad and a mouse. But it might be limited to OS X 10.5.X.
Here's a patch (and tryserver build) that might fix this problem. I'm just guessing, of course (since I still can't reproduce it). But my guess isn't totally random: At the last all-hands meeting, Roc told me that the code I've commented out can sometimes cause events to be processed. This surprised me (and isn't something that Apple's ever documented). I also don't know what events can be processed, or how Roc came to his conclusion. But if this code might process events, it might also cause them to be swallowed or misdirected -- and I already suspect that mouse-up events are being swallowed/misdirected. Here's a tryserver build: https://build.mozilla.org/tryserver-builds/2009-01-27_09:email@example.comfirstname.lastname@example.org Whoever can reproduce this bug -- please try this build, and let us know your results.
I've been able to reproduce the bug in the tryserver build just now.
Comment on attachment 359099 [details] [diff] [review] Trial patch (In reply to comment #53) Sigh :-( So the need for new information is all the more urgent. Markus, Johnathan and Marcia (and others), please test (standard nightlies) with fresh profiles.
Attachment #359099 - Attachment is obsolete: true
Reminder: Please also test with extensions disabled.
Here's another trial patch and tryserver build. I decided to try limiting the kinds of events I send to the app-modal session in nsAppShell::ProcessNextNativeEvent(). https://build.mozilla.org/tryserver-builds/2009-01-27_15:email@example.comfirstname.lastname@example.org Whoever can reproduce this bug, please try this build, and let us know your results.
I am still trying to reproduce the bug in the latest nightlies but I have no luck yet. I will try the tryserver build as well. I think Steven is right that there may be some other thing that has to be going to trigger this bug. At times I have been able to consistently reproduce it with picasaweb and carbonmade, but in my last two tries I was not able to :(
I've managed to reproduce the bug in the second tryserver build, too. I haven't tested with a fresh profile yet.
Comment on attachment 359190 [details] [diff] [review] Trial patch #2 Oh, well. I'll try to come up with another clever guess about a fix.
Attachment #359190 - Attachment is obsolete: true
All: Please do test with a fresh profile. I need to find out if some browser setting (or some extension) makes this bug easier to reproduce.
I can reproduce this every time. Find me on irc and I can do some tests with you.
"I can't believe it's not blocking."
The reason this isn't blocking is because crucial information is still missing. IRC is a terrible way to convey complex information. Far better to try to write up an STR ... even if you have to record one (as johnath did). But better still, try to reproduce the problem with a fresh profile (and no extensions) and in a new account. The missing information may have to do with some OS setting. Finally, I have another idea for a trial patch, which I'll post early next week. I'm taking time off from Mozilla Corp to work on the Java Embedding Plugin (to get it working with SnowLeopard). But I'm still available for "emergencies" ... and this bug may qualify.
Steven, do you mind creating a tryserver build from 1.9.1 too? I would feel much safer in using such a build with my daily profile. I could dig more into this as with a trunk build.
I'm not sure it's possible to do a tryserver build on the 1.9.1 branch. Is it? And if so do you know how to do one?
Uh, yeah. Under "Source:" select "Use another Mercurial repository:" then put in the URL for 1.9.1. That is: http://hg.mozilla.org/releases/mozilla-1.9.1
(There was a bug on creating builds with patches from anything but the m-c repo; I'm not sure if the fix has made it live or not.)
Here's my third trial patch. At Henrik's request, I've done two tryserver builds: mozilla-central https://build.mozilla.org/tryserver-builds/2009-03-02_12:email@example.comfirstname.lastname@example.org 1.9.1-branch https://build.mozilla.org/tryserver-builds/2009-03-02_12:email@example.comfirstname.lastname@example.org If you can reproduce this bug, please try them out. Especially if you can easily reproduce it. I've tested to make sure my patch doesn't regress bug 436373 or bug 442442.
Steven, I've tested the tryserver build for a day now without being able to see this issue anymore. That looks really good. I'm still not sure if we shouldn't really block on this. This issue happens too often and makes the usage on OS X really annoying. I'm able to hit it nearly all the time. Steven, would you still be interested in testing with a fresh profile?
> Steven, I've tested the tryserver build for a day now without being > able to see this issue anymore. That looks really good. Glad to hear it. But I also need to hear from others ... like Vlad, johnath and blizzard. > Steven, would you still be interested in testing with a fresh profile? Yes. Without any extensions. Please also test in a new account. If possible, I'd really like to know how to reproduce this -- i.e. I'd like to know that the (as yet) unknown factor is that allows others to reproduce this yet prevents me from doing so.
I will try the tryserver build as well. As far as blocking, when this bug hits it prevents me from being able to use the browser for uploading files. It is also being mentioned in reports in Hendrix.
I'll give this a shot -- I've been using my Mac mostly in Windows the last little while though, haven't been doing much bugzilla patch attaching from OSX lately.
OK, I'm running this build now. Will report in a day or two.
Steven, I tried the daily builds with another profile. In this case with the one I use for MozMill. It has only the MozMill extension installed. Nothing else. Due to this extension is not installed in my daily profile it shouldn't be the reason. This profile also uses no user preferences. Everything is set to default. But it happens there regularly. Mostly it starts when selecting a shortcut on the left side of the dialog. I'll have a look with another account to see if it happens there too.
Ok, I've created a new user on my machine and started the latest Shiretoko build. Without any modifications on the system and no changes to the preferences of Firefox I'm able to reproduce this problem on http://img1.imageshack.us/. Just clicking on the upload button, selecting several shortcuts on the left side and some folders in the right pane gives me this behavior when I wanted to cancel the dialog. I wasn't able to close it. Clicking outside of the dialog the shortcut to my home folder was getting removed from the list.
The tryserver build from comment 68 (based on m-c) seems to fix the bug for me. I haven't been able to reproduce it the last two days; I used to run into it a lot.
I've been using it too but I haven't had to upload too much stuff today.
Summary: file picker dialog sometimes doesn't close when Open is clicked → File picker dialog sometimes doesn't close when Open/Save/Cancel is clicked
I used this for a while but I couldn't tell if it was fixed. I can, however, verify that the thing that triggers it is to click in the mac sidebar to pick a different location (Music, Pictures, etc.) Happens every time for me.
Just to be clear -- so my patch from comment #68 *does* fix this bug?
For me definitely. It's so much better when having a working file open/save dialog. What is needed to get a patch which will be ready for review, Steven?
Status: NEW → ASSIGNED
I've made several more attempts to reproduce this bug. All failed. But I did (several times) get what looks like a proxy for this bug, on my new MacBook Pro (with the new trackpad) -- which I haven't tested on before. Unfortunately, I rebooted the machine and can no longer reproduce even my "proxy". What I saw (but can no longer reproduce) was the following. If you can reproduce this bug, please tell us if you can also reproduce what I describe below. 1) Choose "Add an attachment" in a bugzilla bug page (for example this one). 2) Click the "Browse" button, and position the OS-provided file picker over the top part of the bugzilla page (where there are text-input fields that make the mouse cursor change shape when you mouse over them, if there isn't a Cocoa app-modal dialog open above the page). 3) Move the mouse around the file picker dialog. Notice that the mouse cursor changes shape when it's over text-input fields in the browser window underneath the file picker.
Aside from Chris Blizzard's ambiguous comment #79, I think we now have enough evidence that my patch from comment #68 really does fix this bug. So I'm going to start the review process.
Sorry my comment was vague. I wasn't able to reproduce the problem in your builds. I am able to reproduce it pretty easily with 1.9.1 builds. So I didn't prove that it was fixed, only that I wasn't able to reproduce. :)
I can reproduce this trying to attach bugzilla attachments. I'm running nightlies, currently http://hg.mozilla.org/mozilla-central/rev/aa75d2c8a862. Should be blocking, esp. if Steven has a patch. /be
Flags: blocking1.9.1- → blocking1.9.1?
> Should be blocking, esp. if Steven has a patch. Please try my patch, and post your results here.
Blocking over my objections: I don't think this happens to the average user enough to block, but am being told that I'll get stabbed if I don't, and fear for the integrity of my epidermis.
Flags: blocking1.9.1? → blocking1.9.1+
This happens to me *constantly* and is very painful. Sometimes I can't seem to get out of the dialog box at all without clicking on the window underneath first. At least once that hasn't worked and I have to force-quit. So I'm glad this is blocking.
+ nsresult PushCocoa(NSWindow *aWindow, NSModalSession aSession); + nsresult PopCocoa(NSWindow *aWindow, NSModalSession aSession); + nsresult PushGecko(NSWindow *aWindow, nsCocoaWindow *aWidget); + nsresult PopGecko(NSWindow *aWindow, nsCocoaWindow *aWidget); Need comments here Instead of writing custom linked-list code, can we just use nsTArray<nsCocoaAppModalWindowListItem>? I presume performance is not going to be an issue, you won't have hundreds of stacked modal dialogs. + if (mList->mWidget) + return PR_TRUE; + return PR_FALSE; return mList->mWidget != nsnull; Can we replace the use of gXULModalLevel with inspection of this list? The meat of the patch looks reasonable.
> Need comments here OK. > Instead of writing custom linked-list code, can we just use > nsTArray<nsCocoaAppModalWindowListItem>? I presume performance is > not going to be an issue, you won't have hundreds of stacked modal > dialogs. In normal usage they shouldn't get stacked more than 2-3 levels deep. Though I'm sure Jesse Ruderman can come up with some pathological testcases :-) So performance shouldn't (normally) be an issue. And the nsTArray template seems powerful enough. I'll give it a try. But I really like linked lists, and (properly implemented) they're not any more complex than full-featured arrays (as provided by nsTArray, for example). In fact they're *less* complex. Someone should write templates for single- and double-linked linked lists. > return mList->mWidget != nsnull; OK. > Can we replace the use of gXULModalLevel with inspection of this list? I'd prefer not to. The nsCocoaAppModalWindowList class (the need for it) will disappear when we address the issues outlined at bug 478073. But we'll continue to need gXULModalLevel (or its equivalent). So I'd like to keep it separate.
Yeah, we should write a template on top of PRCList. I've been meaning to...
For small lists where we don't need to hand out pointers to the list elements, nsTArray<T> uses less memory and fewer heap objects since there are no links and the objects are flattened into the array. You also have the option of using nsAutoTArray<T,N> with no API changes. nsTArray is managing the complexity for you. Linked-list templates would be nice for the situations where we do need linked lists.
(In reply to comment #92) nsTArray is fine -- for arrays. Though it does have something of a learning curve: For example it took me a while to figure out that it does its own constructing and destructing. My point was that linked lists aren't inherently any more complex than full-featured arrays (for example those that automatically allocate more memory as needed, and shift their contents up and down as needed). In fact they're quite a lot less complex. I do understand that it makes sense to encourage people to use the "built-in" implementations of arrays and the like, rather than rolling your own. This makes the code more uniform, and therefore easier to read and maintain. I'd just also like to see "built-in" implementations of linked lists. So we don't have to use arrays to do things they weren't really designed for.
> For example it took me a while to figure out that it does its own > constructing and destructing. Of "elements".
(In reply to comment #95) > > For example it took me a while to figure out that it does its own > > constructing and destructing. > > Of "elements". That's a feature :-).
Attachment #368120 - Flags: superreview?(roc) → superreview+
Comment on attachment 368120 [details] [diff] [review] Patch rev4 (follow Roc's suggestions) Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/0fb1e770c85b
(In reply to comment #94) > I'd just also like to see "built-in" implementations of linked lists. > So we don't have to use arrays to do things they weren't really > designed for. Why not filing a new bug if none exist yet?
Comment on attachment 368120 [details] [diff] [review] Patch rev4 (follow Roc's suggestions) Landed on the 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e4068bf86855
>> I'd just also like to see "built-in" implementations of linked lists. >> So we don't have to use arrays to do things they weren't really >> designed for. > > Why not filing a new bug if none exist yet? Makes sense. I'll do that at some point.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Haven't seen this issue anymore the last days. Shiretoko is usable again. Thank you so much Steven! Verified fixed with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090322 Minefield/3.6a1pre ID:20090322035551 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090322 Shiretoko/3.5b4pre ID:20090322030800
I'd really hate for this to regress again... any chance of an automated test? If not, can we at least get this in Litmus?
This bug doesn't have good STR. So neither an automated test nor a litmus test is feasible.
I added a general test case to Litmus, https://litmus.mozilla.org/show_test.cgi?id=7669, to cover the general functionality of the file picker since there did not seem to be a similar test case already in Litmus.
Flags: in-litmus? → in-litmus+
(In reply to comment #105) > I added a general test case to Litmus, > https://litmus.mozilla.org/show_test.cgi?id=7669, to cover the general > functionality of the file picker since there did not seem to be a similar test > case already in Litmus. Marcia, from my experience it would be great to add some more step which made this bug more visible, e.g. choosing a shortcut from the left hand menu and navigating through a couple of folders.
You need to log in before you can comment on or make changes to this bug.