Sorry you are getting left without any progress reports. This question is a good example of some areas where I think we need to try to enhance Support Forum performance.

I will see what I can find out. Unfortunately it may just be that this is considered low priority and resources are not available to fix it. I do not think Firefox has ever excelled on printing ability and compatibility.

Regrettably I have little chance of finding the related posts you mention.

• The automated closing of threads is a newer improvement coupled with the facts that
  • it also involved stopping Google indexing of old threads,
  • and the fact that even the advanced search will not search for string but OR s all the words together, so maxes out at 1000 results without meaningful hits. (The next improvement is consideration of shelving advanced forum search entirely  ! because it is an under utilised feature.)
• Have you got links to any of them ?

I will start a thread in the contributors forum, at least those threads do not get closed down.

The bug does not seem to have any action on it and is unassigned, but it had a recent comment. (By "Don" - was that you? ) I will see if I can politely prompt someone into giving a status report.

Vaguely related, another printing regression that has stalled and David's involvement including bug684622#c39-40 /questions/936842

I guess primitive clunky workarounds will include

• taking screenshots and printing them or cutting and pasting text into another application,
• or maybe using print to file, and editing the file prior to printing.
• or save the web page, to re-open and print using something else.
• Probably easiest is simply to use an alternative browser

Thanks for the update. I found the other threads by googling "firefox print selection first line".

The "Don" in the last post on the bug report page was me.

The print bug has now been fixed.

edit Some print bugs have been fixed including some pdf issues and bug 684622

Hope your problems will be solved in Firefox 21. That will at present mean using nightly http://nightly.mozilla.org/

John, I looked for info on "print selection" problems being fixed in v21 (any) - can't find evidence. In fact, remarks in the bug on print > selection cutting off 1st line, mentions this post & a fix hasn't been issued.

https://bugzilla.mozilla.org/show_bug.cgi?id=696566#c12

Someone (John99) claims that this bug has been fixed in some nightlys and the fix will be released with Firefox 21

I think he must be confused. There's no indication that this bug is fixed, and I can still reproduce this in Nightly ... So, not fixed yet.

Do you have info that this bug has indeed been fixed?

For some reason, I didn't see the issue of print selection cutting off first line, until about version 18 or 19. Others reported it much earlier. Thanks.

Sorry.

I do not think handling printing is one of Firefox's strong points. There are sometimes multiple printing issues under investigation and in various stages of a fix.

I had intended to say that Bug 684622 had been fixed.

I would say work on bug 696566 is stalled with the last comment from the assignee in 2011

I still haven't figured out what is going wrong with the clipping, none of the variables involved were touched by my patch. 
I'm not surprised this is to do with print selection, perhaps the most broken and badly written feature in the codebase aside from mork.

Perhaps someone should politely ask if anyone is actively assigned to and working on that bug.

It's strange I never saw the cutting off 1st line issue until most recent versions. I do a lot of selection printing - in Vista x64. Never had a problem. Upgraded Fx & suddenly I have same issue others complained about for well > a yr.

Wondering if there isn't some about:config setting that was changed in recent upgrade? How else could I not have the issue for so long, that many reported (in same versions they reported the issue), but suddenly I do?

There are several about:config printer entries - not sure of possible values & action, like: printer_HP_Officejet_Pro_8600_(Network).print_edge_top; Value = 0

printer_HP_Officejet_Pro_8600_(Network).print_unwriteable_margin_top; Value = 0

The printer model isn't a factor - others now also cut off 1st line in print>selection.

I don't think it was an intentional preference change, and different pages still behave differently. In some cases, instead of printing just the selection at the top of the page, Firefox preserved the position on the first page or on any page, printing blank pages up to the page with your selection. (This is an improvement from printing blank pages even after your selection. ?!)

While I don't think print layout is that much harder than screen layout, there seems to be less energy for sorting it out. (And by energy I mean developers willing to devote time to the issue.)

Over the years, I've generally fallen back on a bookmarklet approach. After making a selection, I click the bookmarklet to remove the rest of the page. This and other workarounds are described more thoroughly in this thread: Firefox 17 on Windows 7 prints blank pages after printing selection.

The bug was reported on a Mac and semi automated regression testing done on Linux. You could run the regression testing your self on your machine to see what results you get.

Or you could test a single manual reinstall of one you thought worked (It is probably no more work to run the semi automated test than the additional install )

Thanks for replies. jscher2000 - thanks for link to your script. I'd seen references to a bookmarklet (guess it was yours or one similar) - but didn't actually see the script.

How does the script "stripping" everything except what's selected / high lighted on a page, prevent the 1st line of selected text from being cut off?

Recently, I've tried selections on many pages. I doubt ALL had frames, tables, etc., that caused 1st line cut off. Could be wrong. Also looked at your other links - don't seem to relate to 1st line being cut off.

John - what exactly do you mean

You could run the regression testing your self on your machine to see what results you get.

I understand the words, but no idea where / what you mean. Where is this & is there documentation how to test it?

Yes, I could install older Fx versions. If they stopped the problem, what good would that do? Unless it is an about config setting or something user accessible, won't help w/ current version. What are you proposing there?

Hi Joebt,

How does the script "stripping" everything except what's selected / high lighted on a page, prevent the 1st line of selected text from being cut off?

It doesn't solve any problems with the print selection feature, but it bypasses it because you just print the page normally instead of using print selection.

Got ya. Works as advertised. Seems a bit quicker than copying / pasting part of a web page into something like Wordpad or another app (or one capable of handling HTML), if don't need editing.

Especially once get used to the bookmarklet. Definitely another work around for Fx's long list of things that don't work, or they rely on addons for basic functions. But I'll take it.

Question: When printing selection - using your script or not - not found settings that allow the print out to fill most of the paper width, in many I've tried so far. Even if text on a web page scans entire screen, most prints cover half width (a couple a bit more).

Something's wrong. Most pages can't be set up where they only print a small part of a 8.5 in. page. My Fx margins are set = 0.5 in. When I print a selection from say, Mozillazine forum, it prints a CENTERED 2.75 in. wide paragraph. More or less same w/ several sites I've tried. This was NOT an issue in the past. Worst I've seen Fx print since day one (if it's Fx fault).

Changing Fx page setup - checking / unchecking shrink to fit width or leaving at 100% scale makes no difference. So, not sure where it's getting the margins or font size.

I DON'T have "allow pages to use their own fonts" checked, though not sure that applies to printing vs screen display.

Joe,
You Said

It's strange I never saw the cutting off 1st line issue until most recent versions. I do a lot of selection printing - in Vista x64. Never had a problem. Upgraded Fx & suddenly I have same issue others complained about for well > a yr. 

John - what exactly do you mean
You could run the regression testing your self on your machine to see what results you get.

I understand the words, but no idea where / what you mean. Where is this & is there documentation how to test it?

mozregression

Mozregression is a little utility for semi automated testing to find a regression range.

• documented here
  http://mozilla.github.io/mozregression/

Once installed it has simple commands allowing you to bisect a range of dates looking for a bug. It takes care of installing and starting the particular versions in a discrete separate location and profile. Allows you to do what you wish i.e. run whatever test-case. And then asks whether the result is good or bad. Eventually it reaches the exact spot of the change and will give a result saying what the last good and first bad build was.

Because this is tested on Nightly versions developers know exactly what code changes were made between the versions, and there will be less changes in maybe a single day, than the six weeks between full releases.

It makes it easier for the developers to discover the significant change.

Firefox Version

Yes, I could install older Fx versions. If they stopped the problem, what good would that do? Unless it is an about config setting or something user accessible, won't help w/ current version. What are you proposing there? 

It may help anyone dealing with a bug to know which version of Firefox is affected. It helps you determine if it is the same bug as others are discussing.

For that reason if you do look at a bug report it is a good idea to look up the test case defining that problem and try it yourself.

I see <blockquote> now

indents text on this forum

I did not notice them sneak that change in but I guess it was fairly recent, and maybe not even intentional.

Thanks for the primer. I admit, it is interesting. At the moment, I can't switch to being an Fx dev. Aren't there Mozilla employees that get paid for this sort of thing?

Re: odd / variable print format - after using "Crop4Print" script. Several sites / pages I tested stripping everything after selection, showed normal L aligned margin, on both Fx print preview & print out. Other sites like attached screen, show uneven L margin in print preview & print out, after using the script.

When I copy / paste same text in attached screen to Wordpad, OO Writer, Notepad++, Notepad - the L margin is aligned. I'm sure other pages would give different results, still.

Seems odd - must be something on some pages that it's not stripping, causing varied margin alignment in Fx. Doesn't matter for stuff to be tossed. Printing several pages to keep / use is another matter.

Fx 20 is the weirdest I've seen for printing in a long time. It's like going back to Opera 6 or 7; hit / miss if pages printed correctly or at all. The last thing I want to do is use IE or Chrome, but if others are having as much trouble, plenty will jump ship.

Many less technical or loyal users don't have time or inclination to mess w/ this kind of stuff. I can't blame them.

Re: blockquote. I just tried it, using the very old Text Formatting Toolbar addon.

There are paid developers, but with open source projects not everything gets done and any help is always going to be appreciated.

I get the feeling printing with Firefox is overdue for review, but with so many resources on other projects it probably never will get fixed properly on desktop Firefox.

The explanation for the centering of the text when you use Crop4Print on the Kaspersky forum is that the bookmarklet duplicates the text into a new element that is directly under the <body> tag, and that tag has text-align:center. If you want to force text-align:left, we could built that into the bookmarklet.

(Edited version follows)

javascript:var sel=window.getSelection(); if(!sel.isCollapsed){var rng=sel.getRangeAt(0); if(!rng.collapsed){var docfrag=rng.cloneContents(); if(!document.getElementById("divHideMe")){var rng2=document.createRange(); rng2.selectNodeContents(document.body); var myContainer=document.createElement("DIV"); rng2.surroundContents(myContainer); myContainer.setAttribute("id","divHideMe"); rng2.detach();} myContainer.style.display="none"; if(document.getElementById("printFrag")){var myFrag=document.getElementById("printFrag"); while(myFrag.firstChild) {myFrag.removeChild(myFrag.firstChild);} myFrag.style.display="block";}else{var myFrag=document.createElement("DIV"); myFrag.setAttribute("id","printFrag"); myFrag.style.textAlign="left"; document.body.appendChild(myFrag);} myFrag.appendChild(docfrag); rng.detach(); var myP=document.createElement("P"); myFrag.appendChild(myP); myP.setAttribute("id","killBtn"); var myBtn=document.createElement("INPUT"); myP.appendChild(myBtn); myBtn.setAttribute("type","button"); myBtn.setAttribute("value","Return to Page"); myBtn.setAttribute("onclick","document.getElementById('divHideMe').style.display='block'; document.getElementById('printFrag').style.display='none';"); myStyle=document.createElement("STYLE"); myFrag.appendChild(myStyle); myStyle.setAttribute("type","text/css"); myStyle.setAttribute("media","print"); myStyle.innerHTML="#killBtn{display:none}";}} void 0;

Obviously this leaves much to be desired in the way of retention of formatting, but sometimes nothing else works.

Thanks John & thanks jscher,

I see now that the Kaspersky forum print was centered, like a letter header. Strange, because it's not centered on my monitor. Mighty nice of you to modify the script. I'll test drive it later & let you (& others) know how it works.

John, Mozilla.org is not a poor organization. They make plenty off advertising & deals w/ Google, etc. In fact, their non profit status was being investigated (may still be). Either way is fine w/ me, but they're not strapped for cash. They are, however, losing user share to Chrome & back to IE (as IE continues to improve).

I don't like either one of them because of their business practices, but #s don't lie about market share declining.

At jscher2000:

Wouldn't it be better to use lowercase for createElement() (createElement("input")) to avoid issues with XML pages?

I once noticed that one of my bookmarklets didn't work because of this, so now I'm using always lowercase to reference elements.

Hi cor-el,

Wouldn't it be better to use lowercase for createElement() (createElement("input")) to avoid issues with XML pages?

That makes sense.

Joe,

 In fact, their non profit status was being investigated (may still be).

You may then be interested in

• https://blog.lizardwrangler.com/2012/11/03/mozilla-foundation-irs-audit-now-closed/