Fix Sought for XHTML Charset Detection BugSaturday May 1st, 2004Boris Zbarsky is appealing for someone to fix a bug that causes the charset to be ignored for some XHTML documents: "It'd be nice to have someone come forward and help fix bug 240962. The code that needs fixing is pointed to in the bug, and the bug needs fixing on the 1.7 branch, so what's needed is a minimal change that makes things better. The catch is that it needs some good testing before being checked in, hence whoever picks this up needs to do said testing..." Update: Thanks to James Ross, the bug has now been fixed on both the trunk and the 1.7 branch. Good Luck! this is the first time, in my experience, that mozillazine has actually openly pushed for a specific bug to be fixed. there have been plenty of bugs with simple solutions available that have spent far too much time waiting for someone to pick them up. not that i don't want to see this bug fixed, but what's so special with this one in particular? What's special is that this is a serious recent regression, it shouldn't be hard to fix, just a little time-consuming, and that I cared enough to look for help. Note that I'm not saying "this bug should be fixed; someone needs to do it" like people do when they push for bugs. I'm asking, "is there anyone out there who has time to do it?" Very different sort of thing.... firstly, it's not Mozillazine asking, it's Boris asking on Mozillazine. There's plenty of plugging that goes on, it's just not usually in actual article submissions. if there's a particular bug with a simple solution available that you have in mind, you could try submitting something about it and see if the mozillazine folks think it's worth a separate posting. This bug is a pretty serious regression, which is a blocker for the 1.7 release. so this is the first regression blocker bug with a reasonably simple solution and requiring just a little work, ever? maybe mozillazine should have a "bug(s) to focus on" news item all the time, since the forums and bugzilla may not be sufficient to attract the necessary attention.
That may not be a bad idea... have a "bugs that should not be too hard to fix and need fixing" thing somewhere that can help get more people involved in Mozilla development. I agree that it would be a very useful feature. I've been following Mozilla development for several years now, and have kept meaning to actually contribute code. The only thing stopping me has been the sheer size of the task of getting into the code. If there were some bugs listed somewhere that could easily be fixed by a newbie, I'd definitely get involved. Martin One of the useful aspect of bug days is that Asa and others help new users learn bug triaging and working with bug reports. Maybe there could be a one-day event on IRC where new developers look at a simple component like View Source and go through the process together of making patches for 2 or 3 bugs, just to get the idea of how its done. Also, perhaps there should be a list of bugs (not necessarily easy ones) that Mozilla developers would like to see fixed but don't have the time at the moment, just to help focus effort where it is needed. (I mean a centralized list, not just random postings in the forums or on blogs). > Also, perhaps there should be a list of bugs (not necessarily easy ones) that Mozilla developers would like to see fixed Well bugzilla can do something similar: P3 or higher, severity normal or higher bugs marked 'helpwanted': http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=helpwanted&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&priority=P1&priority=P2&priority=P3&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Another should-be-easy bug. bug 64926 This is the fundamental difference between someone who knows the code and issues involved saying a bug is easy and someone who just wants to push a bug because they feel like it saying it "should be easy" (note the difference in wording, by the way). Bug 64926 is VERY HARD. If you don't believe me, try to fix it. Or even try to decide what a fix should do, exactly. That still hasn't been agreed on after what, 3 years? As I said before in this thread, it'd be nice to have an easy way to get at lists of bugs judged "easy" or "probably easy" by people who actually know what the hell they're talking about... I think the fix should make the top of the zoomed in/out page at the same location as the top of the page in the former zoom level. At least that's the only logical thing to do to me. However, I agree that due to how tables and text will dynamically reflow, I can't see a way to possibly fix this right now. :) > I think the fix should make the top of the zoomed in/out page at the same location as the top of the page > in the former zoom level. What does that mean? How do I apply this algorithm if in the former zoom level the top of the page had a floating image, a line of text in a table cell, and a line of text in a different table cell and after the zoom they end up at three different vertical positions? That is, properly adjusting the vertical position involves understanding what the various bits of the page actually _mean_ so you can evaluate which are important and which are not. That can be sorta tough... Many thanks for James Ross for doing the patching and testing. Wow, good job! That sure was a fast turnaround for something that could have sat for ages. Maybe this should be done more often -- keep a list of 5 or 10 bugs in desperate need of help on the front page or something. I'm sure there's people who would like to help but don't want to sift through tonsa bugs in bugzilla or wait until they dig something up during their use of Mozilla. how about a "bug bar" instead of/next to the build bar? after all, the build bar no longer really functions the way that it used to, it only points to the forums which are just as accessible through the forum link on the front page. or alternate stylesheets could be presumably used to "turn off/on" the build and/or bug bar. just a suggestion. I noticed that Ctrl+N in the download manager in Firefox doesn't open a new window while Mozilla does. Should be an easy keybinding fix. |