After 7.5 years, Firefox finally adds line numbers to view-source:

https://bugzilla.mozilla.org/show_bug.cgi?id=246620

by ecaron • 15 years ago

207 82 15 years ago

bugzilla.mozilla.org

moheeb• 15 years ago

I never understood this. I believe even Visual Studio defaults to having the line numbers off.

So even though errors are reported as to which line number they are on the line number is not displayed on screen by default!?

Is there reasoning behind this?

TheEzEzz• 15 years ago

I don't use line numbers in VS, because clicking on an error message takes me directly to the line I care about.

sur• 15 years ago

In Firefox, viewing the source from the error console highlights the line that the error was on.

zobzu5• 15 years ago

Because you can just "go to line" and the current line is also displayed already. having the line numbers in a side column is redundant, so its far from critical (that's why the bug didnt get fixed).

Personally i also prefer to have the line number in the status bar, because side bar adds visual clutter and isn't really useful.

It's the same with VIM btw. Default setup doesn't have line numbers but you see them in the status bar. Some people like to have line numbers on the side tho.

mmahemoff• 15 years ago

That's quite a while, but actually I think it represents a trend we're seeing in HTML5/webdev, which is increased attention to developer experience.

While fancy components and CSS eye candy will continue to roll out, we're seeing even more work on development/debugging tools, the JavaScript language, and with web intents and web components, the seeds of a more robust reuse model. [http://webintents.org, http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...]

wavephorm• 15 years ago

Just in time for the removal of the "View Source" menu item.

kinetik• 15 years ago

It was moved to the "Web Developer" menu, not removed entirely.

kijin• 15 years ago

I haven't even noticed the move. It's always been Ctrl+U for me.

millzlane• 15 years ago

They've always shown up in the status bar if you put the cursor on a line. You can also press Ctrl+L to goto a specific line number. Just in case someone didn't know.

DiabloD3• 15 years ago

The line to shout FINALLY! at the top of their lungs starts here.

j452• 15 years ago

Haha, I just about wrote the same thing but scrolled down.

Having line numbers will be a nice addition when I'm not using Firebug as a simpler way to quickly find something.

j452• 15 years ago

Just trying to learn about HN. Commenting why having page numbers will help me is a down votable offence?

gcb• 15 years ago

and 7.5 years I still think it's not that useful anyway.

you could always go to a specific line (edit>go to line, or Ctrl+L), which is over 9000% more useful from anyway you look at it.

you also could have seem the line number on the statusbar.

FuzzyDunlop2• 15 years ago

Next on the long-awaited feature list: word wrap in Eclipse.

I can't say I even noticed line numbers on the page source in Chrome either. The formatting of source on a rendered page can be a bit messed up when the request is served, with tabbing and whitespace ended up all over the place, especially with loops. Then there's minified source if you're using someone else's code.

Most of the time it's easier to note the error, try and identify where it occurred, then find it in your editor. And with things like Chrome's developer console, sometimes using view-source is redundant when you have a DOM inspector and a number of ways to traverse it.

And even then, with a good linter you can avoid making basic mistakes like typos or missing parentheses or whatever, and in some cases even have undeclared variables or functions highlighted (Sublime Text 2 has one that in some places can appear quite fascist in how strict it enforces its policies, particularly with Python). At that point, usage of the browser for debugging code is most useful for capturing errors you couldn't reproduce elsewhere, and errors that only appear in minified code.

Not that I'm saying the browser tools aren't a great productivity boost. Because they obviously are. Just that I rarely find myself using the view source feature, really.

ecaron2• 15 years ago

I was waiting for that feature for Eclipse too. But I switched to Sublime Text (http://www.sublimetext.com/2) and shudder when I think how many hours I wasted waiting for Eclipse to keep up with me.

baby2• 15 years ago

Sublime Text 2 is amazing! I'm using it now. 3 big shortcomings though:

* no color picker (I come from dreamweaver)

* no auto-completion of php functions

* the folders/project bar on the left is getting messy really quick (I think the dreamweaver project bar is pretty clear compared to ST2).

easy_rider• 15 years ago

I'm probably switching to Sublime, even though it doesn't autocomp. PHP. whatever, few more lookups in the manual are probably less time-consuming and stressful than an editor just blatantly crashing all over the place when just simply...inputting text

thought_alarm• 15 years ago

The wheels of progress turn slowly, to paraphrase someone talking about mozilla.org in 1999.

scotty79• 15 years ago

Great. Maybe soon disable-output-encoding if Firefox XSLT processing will get implemented.

https://bugzilla.mozilla.org/show_bug.cgi?id=98168

zobzu5• 15 years ago

I think such ones are usually fixed if you make a public fuss about it. Sad but true.

bzbarsky2• 15 years ago

Given that it requires a complete rewrite of how XSLT works in Firefox, that the rewrite would make the XSLT much slower, and that the use cases for XSLT on the web that actually want this feature are few and far between, the chances of this happening are low.

jrockway7• 15 years ago

Well, nobody sent them a patch until two months ago, nobody added tests until a month ago, and nobody fixed the broken tests until yesterday. So the title should be more like, "Firefox adds line numbers to view-source the day after someone implemented them correctly."

This is how Free Software projects work; people that want a feature implement it. It's great that you want something and it's possible that your desires will line up with those of someone who can easily implement them ("oh yeah, great idea, i want line numbers too"), but more often than not, the people with experience on some project are more interested in some deeper problem. If you're hacking on the JS JIT, line numbers just aren't important to you; you never "view source" in the browsers and may not even run the browser all that often. It's likely that your "extracurricular hacking" will be on something like a better test harness or better Emacs integration with your development workflow.

It is hard to go from being a user of software to a developer of that software, especially in this day and age of easily-downloadable TV shows, movies, and /b/ memes. That's why it takes 7.5 years to find someone interested in hacking on this feature, them getting themselves up to speed on Mozilla, and then finally implementing an acceptable patch. It would be nice if someone got paid to work on this sort of stuff, but users are comparing Firefox to its competition with things like Javascript benchmarks and WebGL conformance, not whether the browser has line numbers in view source. That's not to say they're not important, but rather very easy to deprioritize when the people that know how to implement that quickly also know how to implement "bigger wins" more quickly.

Ultimately, a free software project lacks feature X because you haven't added it yet. Remember that when you submit complainy titles to HN. Don't rely on someone else to make your life better because you're going to be pretty disappointed when you realize that you don't matter much to the world at large. Everyone else has other things to do too.

moonchrome• 15 years ago

>This is how Free Software projects work

Isn't Mozilla a non-profit org with a hefty budget ? I guess it isn't unreasonable to expect improvements from the core team. Sure you can't demand them but I guess once you have a paid team working on the project you expect some polish, especially when it coincides with their goals of helping/enabling developers.

jrockway7• 15 years ago

It is, but think about it; all the developers that know how to fix this also know how to fix one of the other million bugs in Firefox. And those are probably more important "to developers" than this one.

All bugs and features are important to someone; the reality is that there is an infinite amount of stuff to do that would be of great benefit to everyone, but only a finite (but perhaps large) number of people that are able to act on. The only way to act purely in your own self interest is to do something yourself; then you get one task and one person to implement it that you have full control over. Acting entitled doesn't get you anything other than the ability to stop giving Mozilla money and switching to Chrome. (But I'm guessing that 99% of people wanting Firefox features aren't giving Firefox any significant amount of money. A feature like this probably takes someone skillful 8 hours to implement. At $100/hr, which is a reasonable rate for an employee with overhead, you should be donating $800 to be entitled to a fix. And that's not even how donations work.)

I'm saying that if this enhancement was truly important, it would have been done sooner. What people think is important and what is important are often very different. "Let the market decide," is my philosophy.

alinajaf2• 15 years ago

I think your point is that if you want a feature implemented in an OS project, you should implement it yourself. In practice, we're web developers, and it's much easier to just pick up google chrome than it is to get set up with developing firefox, getting into the code and implementing the change.

That being said, I'm seriously considering cowboying up and contributing to get the ruby tag implemented in firefox. This is not because I use Firefox myself, but my users do, and faking it with js/css is brittle as hell.

zobzu5• 15 years ago

You can do so, however, note that you still need acceptance for mainline.

Obvious things such as line numbers, are obviously accepted once implemented properly.

Note: the below comment is actually inaccurate, I though ruby tag was the language (as the author mentioned js as alternative). Keeping it for the comments discussing it, but keep in mind I was actually wrong.

Things like a ruby tag might be more complicated than you'd think.

You see, the main difference between Firefox and Chrome (yeah, it's not the UI! ;P) is ideology.

Firefox folks believe in a standard and compatible web. Chrome folks believe in .. implement whatever we think is faster than what we have (or /flamebait hat on, whatever helps Google make money/adverts/lock-in users).

Supporting ruby might fall in the "but it's not standard" "it splits the web" category.

And that's be correct, in my opinion. So you might want to check on that before actually getting the code done, unless you plan to fork.

bzbarsky2• 15 years ago

Note that Firefox did show the line (and column, which is impossible to get in Chrome) number if you actually clicked on any point in the view-source window. It just didn't have a gutter on the left with the line numbers.

As far as the ruby tag, if you really are interested I'd be very glad to get you up to speed. There's a partial patch, but it has some issues that should really get dealt with before it lands. Of course every single ruby implementation out there is broken as hell in the relevant ways, so maybe it should just land issues and all... In any case, let me know if you do want to get it into shape. I do have to warn that this is not a small-and-simple project unless you really want to learn about the layout engine internals anyway.

nn2• 15 years ago

The "switch to something else to fix a bug" strategy is clearly unsustainable. What do you do when you find a bug in chrome then? Switch back to firefox? Switch to opera first before you switch back to firefox? Just change browsers every month in the hope that they all have different bugs?

(chrome has plenty of bugs: the latest update on linux has a tendency to hang and use 100% cpu in some glib functions)

On the other hand to do changes to large code bases on short notice is a big asset to your programming skills. See it as a challenge. It's well something you could put up on your resume.

Often the main challenge is just to find the code, and if you can't do that can you deal with any other non toy code bases? Once you found it a lot problems are easy.

nn -- (who has one patch in Firefox)

baddox• 15 years ago

It sounds like you're saying that the entity called "Firefox" shouldn't be blamed for aissing feature, because it's up to people to write the code. That's a strange definition of what "Firefox" is. I think Firefox is its community of developers, both those that work on the product full time and those that volunteer. A lack of such an obvious feature is in my eyes a problem with "Firefox."

jamesaguilar5• 15 years ago

Depends on which Firefox you are talking about. If you're talking about "the community of people and organizations that develop the browser called Firefox," then your post is correct.

On the other hand, if you are looking at Firefox from the perspective of a consumer deciding between browsers, then the complaint is valid, assuming line numbers are important to you. They are kind of basic, and the product has gone long without having them.

> Ultimately, a free software project lacks feature X because you haven't added it yet.

This is also true of proprietary projects. I can edit the machine code or clone it. This fact doesn't invalidate observations of behind-the-times features in proprietary projects. In OSS, the barrier to entry is lower, but still substantial. Likewise, it's reasonable for us, as consumers, to observe when OSS projects don't implement things we want. I don't hold them to different standards merely because I have been invited to spend my valuable hours working on them.

jrockway7• 15 years ago

I guess I will boil my argument down to: it's not their fault it's bad, it's your fault you're using it.

This applies equally to Free Software and proprietary software. "Don't like it? Don't use it." Your complaining isn't going to make the software better.

Decide on a course of action that will resolve your complaints, and then act on it. Posting to HN, "look at those l4m3rz at Firefox not implementing my features! They suck!" does not count because the logical conclusion of this action does not lead to increased happiness (either yours, or the wider community). It's like a little kid complaining to his teacher, "Johnnie hit me!", the teacher asking Johnnie "Why'd you hit Bobby?", and Bobby saying "Because Johnnie hit me first". The end result is a couple of sore schoolkids and an irked teacher. As adults, we need not let our actions devolve this way.

So, if this issue bothers you, you need to suck it up and stop using Firefox, or suck it up and implement the damn feature that you obviously care so deeply about. If you don't care about your feature enough to implement it, why should anyone else? Why are other people different from you? Because they've implemented features before? You expect free work from people that have given you a free product, simply because they have proven themselves willing to work for you for free before? Right, that make sense.

The advantage that free software projects have over "don't like it, don't use it" is that any user can change the software and other users will be thankful for the time and effort you put in. That's what being an adult is like.

Ultimately, all free software is based on altruism; people contribute because they want to. If you don't understand the concepts altruism or community and just want to take and complain, then you're not going to get any argument about how you should take ownership of issues that concern you.

akkartik8• 15 years ago

Please provide a criticism of open source software which you can't answer with "If you don't like it, fix it."[1] I wager you can't. If that's true, you're basically claiming that open source projects are immune to criticism[2].

[1] It's really, "If you don't like it, learn programming, then download the source code, then learn to build it, then learn to read it, then make your change, then build it, then use it, then champion getting it merged."

[2] Complaint, whine, we can call it whatever you want. I'm a grown man secure in my whining.

---

Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively). It's utterly disingenuous to so ignore the fixed costs inherent in programming.

---

Is this the same firefox that can afford to advertise in the NYTimes? How much of its development is really on a volunteer basis anymore? Let's decide once and for all whether this is a mature codebase that's encouraging us to use it for mission-critical work in the world. If it is, it's open to criticism (yes, even trivial criticism).

Zev2• 15 years ago

Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively).

Yes. At least when the codebase is in a paradigm that I'm familiar with. Note: language is not important in exploring a codebase. I probably couldn't do this with, say, GHC. But, I bet I could with Clang or a js library, if I wanted.

While I might not know my way around the codebase, I can certainly use grep to find where I need to go, or just ask someone on irc. In a few hours, I can at least find where I need to be, and be hacking.

The end result might not be good enough to send in as a patch, but it'll certainly fulfill my needs.

Sure, I have some skills that others don't. But, I'm not the only one who can do this, either.

skore10• 15 years ago

Not "immune to criticism", but set up in such a way that criticism always has a specific, useful outcome.

Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?

And it's not just "here, hack our code to make it work for us", although that is of course preferred. It's already useful to have people report problems or to talk to people who work on the code on forums. It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset. If that's not your thing - no problem. But for some people, it is, and that's how the software grows.

As for the comment about advertising: Mozilla does collect money on Firefox (through Google, mostly, IIRC) and uses the money to advertise it. Advertisement brings more users in who may be interested in participating.

They are simply not your standard software corporation that turns money into software and software into money.

saturn• 15 years ago

By this logic, it is impossible to evaluate any open source project, because all that ends up being evaluated is the reviewer's personal failure to implement whatever qualities they were looking for.

rimantas• 15 years ago

  > This is how Free Software projects work

I'd argue that was the opposite how Firefox project worked when Blake Ross was still guiding it. Clear vision and direction, not passive wait for someone to submit something. Without this any project just becomes a mess of patches.

jrockway7• 15 years ago

That's simply not true. Maintainers exist to coordinate effort, not to do all the work themselves.

A good example is GNU Emacs. There are two maintainers, but most of the code is written by other people. Even RMS' code doesn't amount to a particularly large percentage of Emacs anymore.

stfp• 15 years ago

And no other feature was implemented in that timespan! Outragealicious!

markokocic• 15 years ago

The title is a bit misleading. It's not that they were trying to add them for 7.5 years, but weren't able to do it, as the title suggests. It's just that hey didn't have intention of adding line numbers, but changed their minds recently.

tzury• 15 years ago

Seems like some of Blake Ross' code was not touched since his departure many years ago.

    1.11   *   Blake Ross <BlakeR1234@aol.com>
    1.12 + *   Geoff Lankow <geoff@darktrojan.net>

After 7.5 years, Firefox finally adds line numbers to view-source:

Related Stories