User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3 Double-clicking text now seems to select the whole line instead of just the current word (this used to be triple-click behavior). I observe this both for page text and in inputs and textareas. Reproducible: Always Steps to Reproduce: 1. Double click on a word in some text. Actual Results: The whole line is selected. Expected Results: Only the current word should be selected. This regression occurred between Bon Echo A2 and A3. In fact, looking at nightly builds, it seems to have appeared between 2006-05-25-04-mozilla1.8 and 2006-05-26-04-mozilla1.8. I haven't tested whether the behavior has also changed in other products or on other platforms (I am running Mac OS 10.3). I've gone ahead and labeled this bug as "major", since I'm finding the behavior absolutely maddening and I expect that others will as well. If anyone thinks that's overstating the case, feel free to downgrade the severity.
If that regression range is correct, then I guess this is a regression from either bug 336696 or bug 337334. It would be good to determine whether this is Mac-only.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3 Double-clicking selects a word here.
FWIW, I don't see this in tonight's Camino 1.8nightly (2006-05-29-04, rv:1.8.1a3); double-clicking selects a word (bugs on "what is a word" aside), if that helps rule out possible bugs (10.3.9 here, also).
WFM in: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a3) Gecko/20060529 BonEcho/2.0a3
(In reply to comment #1) > If that regression range is correct, then I guess this is a regression from > either bug 336696 or bug 337334. It would be good to determine whether this > is Mac-only. Backing out the patch to bug 337334 seems to fix the problem for me. Given that all this patch does is load Cocoa, the bug is pretty certainly limited to the Mac platform. But that also makes it a bit puzzling why there would be any change in behavior at all: as far as I know, Firefox isn't actually _doing_ anything with Cocoa, just loading it. (Then again, I know pretty much nothing about what loading Cocoa actually does.) Just to give a bit more information, I'm running Mac OS 10.3.9 on a 1.25 GHz G4 Powerbook with 512 MB RAM. I see this behavior consistently in both my main testing profile and in a new blank profile that I created specifically to test this bug. I first noticed the bug in my own build from CVS (and that's where I've now convinced it to go away), but as noted previously I've seen it both in the alpha 3 release and in nightly builds so I don't think that my particular build configuration is to blame.
NSApplicationLoad (aka the bulk of the fix for bug 337334) just got backed out (bug 339389), so make sure this goes away in the next nightly, Steuard :) > change in behavior at all: as far as I know, Firefox isn't actually _doing_ > anything with Cocoa, just loading it. (The 8bit-alpha icon decoder in the download manager was calling Cocoa.)
(In reply to comment #6) > NSApplicationLoad (aka the bulk of the fix for bug 337334) just got backed out > (bug 339389), so make sure this goes away in the next nightly, Steuard :) Yup, it's gone. Or at least, it's gone in my latest CVS build, and that's good enough for me. I'm resolving this as "Fixed" by the checkin for bug 339389. (Incidentally, I've already mentioned over there that it looks like the Cocoa framework is still being referenced in the Mac widget Makefile.in; my guess is that it should be removed in order to fully revert the patch from bug 337334.)