| |||||||||||||
OfftopicOfftopicPosted May 26, 2008 17:28 UTC (Mon) by ikm (subscriber, #493)Parent article: Fsyncers and curveballs (the Firefox 3 fsync() problem)
Am I the only one who has a problem in ff3 where pressing right mouse button on a link to bring up context menu sometimes does some random action with this link instead (opens it in a new window, adds to bookmarks, and so on)? I just wonder, this looks like a really obvious problem, but it was in b5 and now continues to be in rc1.
(Log in to post comments)
Offtopic Posted May 26, 2008 17:40 UTC (Mon) by MisterIO (guest, #36192) [Link] No, you're not the only one. It's one of the many problems I was talking about in a previous post.
Offtopic Posted May 27, 2008 2:22 UTC (Tue) by roc (subscriber, #30627) [Link] This bug is hard to fix because none of the developers who could fix it ever see it. See http://ubuntuforums.org/showpost.php?p=4744527&postco... ; please provide your feedback in the upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=404314
Offtopic Posted May 27, 2008 4:25 UTC (Tue) by MisterIO (guest, #36192) [Link] Another funny bug( :-( ) is that of the magical disappearing images! It was present in B5 and it's still there! The funniest part is that those images which disappear are still selectable with a right-botton click and downloadable(etc.). It's a kind of magick!
Offtopic Posted May 27, 2008 18:50 UTC (Tue) by zlynx (subscriber, #2285) [Link] I've seen this also. What I finally noticed is that on really big images you can see the image top-left corner starting way down, shifted right and down in the image frame. It gets worse the more it's zoomed.
Another regression Posted May 27, 2008 3:22 UTC (Tue) by dskoll (subscriber, #1630) [Link] I can't print. :-( That makes FF3 basically... useless. https://bugzilla.mozilla.org/show_bug.cgi?id=430818
Another regression Posted May 27, 2008 3:33 UTC (Tue) by roc (subscriber, #30627) [Link] I guess GTK's print setup is broken somehow on your system. It's actually interesting. Every time we try to make people happier with deeper GTK integration, we end up hurting some people when the GTK solution doesn't work well in some circumstances.
That's Ok Posted May 27, 2008 7:36 UTC (Tue) by khim (subscriber, #9252) [Link] If something is not used by user at all and it starts to be used - expect the breakage. The only way to "solve" this problem is to change nothing - and this leads to "XP forever" campaigns... It's Ok for BETA version of software to depend on new but RELEASED version of library. Most distributions include GTK 2.12 nowadays and if someone wants to use something ancient - that's their problem. Sid includes GTK+ 2.12 too so once Debian will manage to issue new release - problem will be in the past.
Another regression Posted May 27, 2008 13:56 UTC (Tue) by dskoll (subscriber, #1630) [Link] I guess GTK's print setup is broken somehow on your system. Very possibly; this is on Debian Etch which is too "ancient" for the Firefox gurus. I had to install a private copy of gtk+ Every time we try to make people happier with deeper GTK integration, AIEE. Every time Firefox gets deeper GTK integration, I get unhappier, because formerly-working stuff starts breaking, or formerly-fast stuff gets miserably slow (ie, the grotesque GTK+ file browser which mercifully can be turned off in about:config) Anyway... even if CUPS is busted, Firefox should at a minimum offer to produce a Postscript file. Printing using "lpr" works fine for me if only I could convince the #*$&&*#$ web browser to write a Postscript file...
VERY bad idea Posted May 27, 2008 21:33 UTC (Tue) by khim (subscriber, #9252) [Link] Anyway... even if CUPS is busted, Firefox should at a minimum offer to produce a Postscript file. To make it happen you need to keep the whole another printing library around. That's Windows way: sure with Windows NT core it's easy, but Windows95 it's still popular so let's use old library. And then plug new one in old if we need some effects. Then and patches to fix gotchas and another patches to fix problem introduced by patches. Then 10 years down the road you need 2GB or RAM and two cores just to print two pages of text. Not a good idea. May be it was to early to switch to gtk-print, may be not (after all Firefox is not released yet and may be Debian will manage to ship another release before that happens), but to have TWO print subsystems is just crazy.
Firefox GTK+ Integration Posted May 27, 2008 14:22 UTC (Tue) by GreyWizard (guest, #1026) [Link] Well, I for one appreciate the deeper GTK+ integration, even if it occasionally creates short term problems for me. You can't please everybody, but making the browser work consistently with the underlying platform is the right thing to do.
Firefox GTK+ Integration Posted May 27, 2008 14:51 UTC (Tue) by dskoll (subscriber, #1630) [Link] You can't please everybody, but making the browser work consistently with the underlying platform is the right thing to do. And if your underlying platform is KDE/Qt instead of gtk? (Not that mine is, but there are a significant number of Linux users who use KDE.) Breaking formerly-working code and making formerly-fast code slow is never the "right thing to do".
Firefox GTK+ Integration Posted May 27, 2008 15:37 UTC (Tue) by GreyWizard (guest, #1026) [Link] Breaking working code and slowing down fast code are consequences of making progress toward other goals that the developers believe are more important. This is especially true for "beta" or "release candidate" software. The bugs have been reported and they'll be fixed when the necessary resources are available so it's not clear what you think you're going to accomplish by ranting. If your underlying platform is KDE/Qt then you should use a browser that integrates with these technologies or learn to live with the consequences of using one that doesn't. I think it would be great if Firefox offered a KDE/Qt integrated version in addition to the GTK+ port, but as far as I know they don't yet. You could try Konquerer. In any case whining is not going to help you.
Firefox GTK+ Integration Posted May 27, 2008 17:03 UTC (Tue) by dskoll (subscriber, #1630) [Link] Breaking working code and slowing down fast code are consequences of making progress toward other goals that the developers believe are more important. True, but what do users believe to be more important? And usually by the time you have a "Release Candidate", you've fixed up the obvious breakages. As I wrote, I don't use KDE, so I'm not looking for a KDE/Qt browser. I do get alarmed when Firefox developers break stuff and don't undo the breakage. For example, I filed a bug asking for Firefox to default to the (fast) built-in filebrowser dialog (which still ships!) rather than the (slow and broken) GTK+ filebrowser, but met with a negative response. So the question is: If you ship a superior filebrowser, why do you choose to use the stupid one by default??
Firefox GTK+ Integration Posted May 27, 2008 17:33 UTC (Tue) by GreyWizard (guest, #1026) [Link] Hopefully the users and developers agree about what's important but the users are more numerous and their opinions vary more. To make matters worse, each believes he or she is representative of the rest. For example, you're asking for continued default use of a custom file browser for the GTK+ port and you seem to believe this is what everyone wants or should want. It's not what I want. I want the same file browser every other GTK+ application uses. That saves me the trouble of mastering the quirks of two incompatible systems for doing the same thing. I don't mind working around a few bugs for a while to get there. Which of us is actually more representative of the mainstream of Firefox users is a difficult question but for now the Firefox developers seem to think it's me. I won't argue with that. :-)
Firefox GTK+ Integration Posted May 27, 2008 20:25 UTC (Tue) by dskoll (subscriber, #1630) [Link] Hopefully the users and developers agree about what's important but the users are more numerous and their opinions vary more. Yes of course! That's part of the joy (challenge?) of actually having customers. Commercial software producers (like my company) have to listen to their customers. Open-source ones should too. For example, you're asking for continued default use of a custom file browser for the GTK+ port and you seem to believe this is what everyone wants or shouldwant. I don't specifically want the use of a custom file browser. I want the continued use of a fast file browser. We're talking orders-of-magnitude speed difference: http://lwn.net/Articles/279345/ I want the same file browser every other GTK+ application uses. Even if said file browser is three orders of magnitude (yes, 1000X) slower?
Firefox GTK+ Integration Posted May 27, 2008 20:58 UTC (Tue) by GreyWizard (guest, #1026) [Link] Yes, even if the GTK+ file browser is three orders of magnitude slower I'd rather use it. Don't get me wrong, I would be happy to see whatever bug is causing that performance difference fixed but it's just not a problem for me in practice so I won't be the one submitting the patches. I spend at most a fraction of a percent of my time at the computer using the file browser and I believe that's true for most people. Optimizing it in just one application at the expense of a consistent user interface is a poor trade. As for listening to customers, you're implication that free software projects don't is mistaken. They do, but there are too many users with too many requests to satisfy everyone, just as there are for successful proprietary products. Available resources are spent according to what seems to be most important. You clearly have a different idea of what's important than GTK+ and Mozilla developers but this alone doesn't prove that they're wrong.
Firefox GTK+ Integration Posted May 27, 2008 23:10 UTC (Tue) by dskoll (subscriber, #1630) [Link] Yes, even if the GTK+ file browser is three orders of magnitude slower I'd rather use it. * boggle * OK, you've got me there. :-) Optimizing it in just one application at the expense of a consistent user interface is a poor trade. Well, the Firefox developers still ship their own (fast) filebrowser, something no GNOME app does. Why is that, I wonder? Consistency is overrated, IMO. If I wanted a brain-dead-boring "consistent" interface, I'd get a Mac (and I'd feel like I was wearing a straitjacket). I like my tweakable idiosyncratic interface, thanks, especially if it gives me a 1000x speedup. Anyway... this is getting a bit off the original thread topic, which is that FF3 has introduced several important regressions. If printing used to work and is now broken with no workaround by printing to a file, I don't really care about developer goals or justifications. From my point of view, it's just a project moving in the wrong direction.
Firefox GTK+ Integration Posted May 28, 2008 10:46 UTC (Wed) by Los__D (guest, #15263) [Link] If printing used to work and is now broken with no workaround by printing to a file, I don't really care about developer goals or justifications. From my point of view, it's just a project moving in the wrong direction. NOTABUG, the problem is with your system, not the browser.
Firefox GTK+ Integration Posted May 28, 2008 11:47 UTC (Wed) by dskoll (subscriber, #1630) [Link] ISABUG. Even if you find no printers, produce Postscript.
Firefox GTK+ Integration Posted May 28, 2008 11:57 UTC (Wed) by Los__D (guest, #15263) [Link] FEATUREREQUEST ;)
Firefox GTK+ Integration Posted May 28, 2008 13:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] REGRESSIONNOTAFEATUREREQUEST. :-) FF 2.0 will produce PostScript even if it doesn't detect printers, AFAIK.
Firefox GTK+ Integration Posted May 29, 2008 0:07 UTC (Thu) by roc (subscriber, #30627) [Link] Sure, because FF2 had its own print dialog with its own CUPS integration etc. But there were a lot of problems with that, so we switched to the GTK+ print support. Now you will say that to ensure things keep working for all users, we need to ship support for the old print code as well as the GTK+ integration code. Of course, if we did that, people would complain about bloat. Can't win.
Firefox GTK+ Integration Posted May 29, 2008 2:53 UTC (Thu) by dskoll (subscriber, #1630) [Link] I don't care if you only ship a print dialog with gtk+ print dialog support providing you have a way to generate Postscript to a file. Surely the Postscript rendering code needs to be built into Firefox anyway?
Firefox GTK+ Integration Posted May 29, 2008 5:53 UTC (Thu) by roc (subscriber, #30627) [Link] We wouldn't want to provide "available by default" UI for a feature that only people with broken print setups would use. Someone could write an extension though. This PDF output extension might work for you if you can post-process the PDF. It probably only needs slight tweaks to make it output PS instead. https://addons.mozilla.org/en-US/firefox/addon/5971
Firefox GTK+ Integration Posted May 29, 2008 12:45 UTC (Thu) by dskoll (subscriber, #1630) [Link] Print-to-PDF extension is perfect. Thank you!
Firefox GTK+ Integration Posted May 28, 2008 18:57 UTC (Wed) by GreyWizard (guest, #1026) [Link] Are you seriously unable to understand why Firefox ships their own file browser while GTK+ applications don't? Seriously? Have you ever participated in a substantial software development project in any way? That's a rhetorical question: it's clear that you haven't. If you had you might understand that micro-benchmarks are not a sane way to judge entire applications, that development resources are limited and that no project can be all things to all people. It's too bad you're not happy with Firefox 3. I am. The developers have clearly put in a tremendous effort and have done an excellent job improving things that really matter including memory management, Javascript performance and platform integration. I'm impressed with the result and grateful for the hard work that made it possible. I think I'm not alone.
Firefox GTK+ Integration Posted May 28, 2008 19:53 UTC (Wed) by dskoll (subscriber, #1630) [Link] Are you seriously unable to understand why Firefox ships their own file browser while GTK+ applications don't? I understand it perfectly. What I don't understand is why they don't use it by default. The gtk+ fans could always change the setting to get the gtk+ browser, but it seems to me that you should choose sensible defaults, not orders-of-magnitude-slower defaults. Have you ever participated in a substantial software development project in any way? That's a rhetorical question: it's clear that you haven't. Funny man. I've been writing both commercial and open-source software for the last 18 years in areas ranging from large EDA systems to image-processing, text-processing, networking and personal productivity tools. I own a company that develops commercial software. If you really want, I can e-mail you my resume. However, you don't need to be a software author to realize that breaking formerly-working functionality (especially core functionality like printing) is a Bad Thing.
Firefox GTK+ Integration Posted May 28, 2008 19:55 UTC (Wed) by dskoll (subscriber, #1630) [Link] Oh, one more thing, I'm immensely grateful to the Firefox developers. All of my criticism is only intended to make Firefox better; I don't mean anything personal by it.
Firefox GTK+ Integration Posted May 28, 2008 20:29 UTC (Wed) by GreyWizard (guest, #1026) [Link] As I've already explained, using the Mozilla file browser by default would be the wrong choice. For most users the GTK+ file browser is used infrequently and works more or less instantaneously. Almost no one would even notice a three order of magnitude performance improvement in an number that's nearly zero. But they most certainly *would* notice and suffer from a file browser that's inconsistent with the rest of their working environment. Cognitive resources are much more important than the computational kind, so doing what you ask for would be a serious usability mistake. Now, you may have some unusual usage pattern that makes you particularly sensitive to file browser performance. Go ahead and switch to the built-in file browser if that helps. Better yet, find the bug in the GTK+ file browser and submit patches. But don't burden everyone else with poor usability just to satisfy your absurd obsession with a boring corner case. No, I don't want your resume. That would be even less convincing than your chest thumping about "18 years" of writing software. Whatever your experience you've somehow managed to avoid mastering enough of the fundamentals to understand why breaking printing functionality for one user out of millions in a release *candidate* that delivers major performance improvements and new features is not a catastrophe.
Firefox GTK+ Integration Posted May 29, 2008 1:37 UTC (Thu) by ikm (subscriber, #493) [Link] > Almost no one would even notice a three order of magnitude performance improvement in an number that's nearly zero You should try "Open with..." sometimes. Then you'd actually understand what the fuzz is all about here.
Firefox GTK+ Integration Posted May 31, 2008 3:00 UTC (Sat) by GreyWizard (guest, #1026) [Link] I have. I use it quite often with Firefox 3 Beta 5 on a low end laptop and it's practically instantaneous for me. I'm not sure what your problem is, but the right answer is to identify the bug and fix it in GTK+ not to leave an inconsistent file browser as the default.
Firefox GTK+ Integration Posted May 29, 2008 2:50 UTC (Thu) by dskoll (subscriber, #1630) [Link] For most users the GTK+ file browser is used infrequently and works more or less instantaneously. Umm... have you tried it? Try the Open With... dialog. Look, I don't know what percentage of Linux users use GNOME, but it's probably 50% or less. So the people who don't use GNOME have the choice between an irritatingly non-standard but fast file browser, or an irritatingly non-standard and agonizingly-slow file browser. GNOME users are luckier; at least their agonizingly-slow file browser is "standard". On my machine, the gtk+ browser takes about 25 seconds to browse /usr/bin wherease the Mozilla version is too fast to time. Why is that? The gtk+ browser, when faced with files without extensions, opens and reads a bit of every single file to identify the file type (by "magic") so it knows which pretty little icon to display. If that isn't abominable, I don't know what is. Better yet, find the bug in the GTK+ file browser and submit patches. I filed a bug with the gtk+ authors. Someone else has even submitted patches. They have not (to my knowledge) been accepted. As for breaking printing not being a "catastrophe", you are right. But it is a major regression and stumbling block, and to argue otherwise is simply absurd.
Firefox GTK+ Integration Posted May 31, 2008 3:35 UTC (Sat) by GreyWizard (guest, #1026) [Link] I suspect you're running an ancient version of GNOME and GTK+. On a Fedora 9 system browsing /usr/bin from "Open with..." seems snappy to me even on a low end laptop. Most likely the file magic problem you're describing got fixed some time ago. Furthermore your point about GNOME is similarly outdated because the file browser is part of GTK+ itself these days. So it's standard for all GTK+ applications. Breaking printing for all users would indeed be a catastrophe (or at least it would in a final release, which hasn't happened). But that isn't the case here. So far all we've established is that printing is broken for one user with an unusual configuration. That's unfortunate and certainly a stumbling block -- for you -- but it's not a major regression from the perspective of the Firefox team and certainly doesn't indicate that the project is moving in the wrong direction. To argue otherwise is to expose an inflated sense of your own importance.
|
|||||||||||||