Why isn't FF as good at printing web pages as IE?
Restorm
websites, leaving the rest blank. This has been a known bug for all this
time, yet I still have to switch to IE to print from my own website
(such as http://www.resolutionfund.com/Seminars-Rewealth.html). If you
go to that sight in FF and do a "Print Preview", you'll see that all
pages after the first are blank. This is how they come out of the
printer, too. IE shows those pages in Preview mode, and prints them
fine. How can the FF developers continue to ignore such a major bug?
It's embarrassing when I recommend FF to my friends, and then later have
to explain to them that they need to use IE to do something as simple as
printing a web page.
C A Upsdell
What happens if you fix the 23 HTML errors and 64 CSS errors? Does your
problem persist?
C A Upsdell
Also, what happens if you use a DOCTYPE which triggers standards mode
instead of quirks mode?
David Pyles
beyond the borders of one page. I agree with you, this has been a
problem forever and the Devs should do something to fix it.
Dave Pyles
Lou
The devs do NOT care!!!!
Probably own MS stock/
Lou
Beauregard T. Shagnasty
> On 10/16/2009 2:39 PM, Restorm wrote:
>> For years, FF has only been able to print the first page of many
>> websites, leaving the rest blank. This has been a known bug for all
>> this time, yet I still have to switch to IE to print from my own
>> website (such as http://www.resolutionfund.com/Seminars-Rewealth.html).
>> If you go to that sight [sic] in FF and do a "Print Preview", you'll
>> see that all pages after the first are blank. This is how they come
>> out of the printer, too. IE shows those pages in Preview mode, and
>> prints them fine. How can the FF developers continue to ignore such
>> a major bug? It's embarrassing when I recommend FF to my friends,
>> and then later have to explain to them that they need to use IE to
>> do something as simple as printing a web page.
Restorm, you say "many websites" ... got a couple other samples that do
this same thing?
> Firefox has never been able to print web sites that have tables that
> run beyond the borders of one page.
Do you mean vertically, David? I have lots of pages with tables (of
data, not nested for presentation) that extend for many pages and print
just fine.
> I agree with you, this has been a problem forever and the Devs should
> do something to fix it.
Way back in the bad old days .. Netscape 3? 4? .. tables with missing
tags would not even render.
As an experiment, I copied the page in question to my local server, and
removed parts. When I cut out all the lines for <table>, <td>, and so
forth, leaving all the <p> and other markup, then the print preview
works fine. I'd say there are some mismatched table parts in there.
I blame it on the Microsoft product which generated the page. <g>
Nested tables for presentation is so last millennium.
--
-bts
-Friends don't let friends drive Windows
David Pyles
tables for formatting, right or wrong or out-of-date. Firefox should be
able to print them. The page will print in Oprea, IE and Chrome. but
not Firefox. I'm as big a Firefox supporter as anyone, but it should
print nested tables.
By forever, I mean since the first version of Firefox.
As to the tables tags not matching. I just went through the page and
removed everything except the TABLE, TR, TD, etc, tags anr I was lest
with a set of table tags that do match.
Dave Pyles
Beauregard T. Shagnasty
> On 16.10.2009 22:37, CET - what odd quirk of fate caused Beauregard T.
> Shagnasty to generate the following:? :
>> David Pyles wrote:
>>> Firefox has never been able to print web sites that have tables that
>>> run beyond the borders of one page.
>>
>> Do you mean vertically, David? I have lots of pages with tables (of
>> data, not nested for presentation) that extend for many pages and
>> print just fine.
>>
>> Way back in the bad old days .. Netscape 3? 4? .. tables with
>> missing tags would not even render.
>>
>> As an experiment, I copied the page in question to my local server,
>> and removed parts. When I cut out all the lines for <table>, <td>,
>> and so forth, leaving all the <p> and other markup, then the print
>> preview works fine. I'd say there are some mismatched table parts in
>> there.
>>
>> I blame it on the Microsoft product which generated the page. <g>
>>
>> Nested tables for presentation is so last millennium.
>
> as a "very long time user" of FF,
Me too. Version 0.4 (the first release). Currently using 3.0.14.
> I doubt your assertions.
Which assertions? That I removed the OP's nested tables, and it printed
correctly? Or that Netscape wouldn't render with table tag errors?
> as other "long time users" have asserted, FF as NEVER been able to print
> multiple pages - NEVER.
How, for example, do you see these two pages?
http://news.google.com/
http://www.cnn.com/
Beauregard T. Shagnasty
> ummmmm - how do I SEE them, or how do they PRTNT ?
How do you see them in Print Preview .. or on your printer?
Beauregard T. Shagnasty
> As to the tables tags not matching. I just went through the page and
> removed everything except the TABLE, TR, TD, etc, tags anr I was lest
> with a set of table tags that do match.
Heh, that's the long way round, but yes, they do all match.
Not a good test for printing though, as it's less than one page long.
David Pyles
> David Pyles wrote:
>
>> As to the tables tags not matching. I just went through the page and
>> removed everything except the TABLE, TR, TD, etc, tags anr I was lest
>> with a set of table tags that do match.
>
> Heh, that's the long way round, but yes, they do all match.
>
> Not a good test for printing though, as it's less than one page long.
>
mis-matched table tags and I just wanted to check and see if that was
the problem, but it wasn't.
OK, I have no more time for this silly thread.
Dave Pyles
Restorm
blindly defend FF by attacking my (admittedly antiquated) site for
faults that have nothing to do with the problem.
Restorm
properly and FF doesn't...it's as simple as that. I find it hard to
believe that you are a long-time user of FF, and have never run across
this problem before. It's quite common. Unfortunately, I have neither
the time or the motivation to dig up more examples for you. Sorry.
Restorm
print properly, just that those (as David Pyles points out) that have
tables spilling over from one page to another.
Restorm
mismatched table tags causing a problem that I should fix? - Storm
Restorm
> On 16.10.2009 23:16, CET - what odd quirk of fate caused David Pyles to
> generate the following:? :
>
>> Firefox should be able to print them.
>
> wonder it the devs have teeth that HURT. ??
>
>> The page will print in Oprea, IE and Chrome. but not Firefox. I'm as
>> big a Firefox supporter as anyone, but it should print nested tables.
>>
>> By forever, I mean since the first version of Firefox.
>>
>> As to the tables tags not matching. I just went through the page and
>> removed everything except the TABLE, TR, TD, etc, tags anr I was lest
>> with a set of table tags that do match.
>> Dave Pyles
>>
>
>
> a BUG, in MY code??
> Never!
>
> reg
Whoops: forget my last comment, Dave. I guess you were talking about
Reg's bugginess, not mine (mine's far, far worse, I assure you, Reg).
Ron Hunter
I can easily explain that, because I also have never encountered it. I
VERY seldom print anything, and almost never print multi-page tables,
although when I do from the only website that I use that has these
tables, it prints just fine. So, perhaps there IS something in the site
that causes the problem. Just for the information, what software
generated your website code?
Lou
> On 16.10.2009 22:37, CET - what odd quirk of fate caused Beauregard T.
> Shagnasty to generate the following:? :
> as other "long time users" have asserted, FF as NEVER been able to print
> multiple pages - NEVER.
> quietly made his exit - bloody coward that he is!
> No medals to be earned, no correction�s to bad code made - that's
> Mozills Development for you!
>
> reg
Thanks for the info
John McGaw
I suspect that this is more a case of bad pages printing badly. I can go to
the longest page on my website and print it and it comes out perfectly
spanning multiple printed pages. Of course I don't use tables for
formatting or commit the other sins which passed for web page design from
the bad old days. I'd like to see a page perfectly compliant with all
applicable standards and using modern practices which refuses to print
properly in FF. Purgamentum init, exit purgamentum...
Jay Garcia
--- Original Message ---
I would put money on the fact the you probably used FrontPage to
generate your site. Looking at some of the tags such as MSFPHover for
example is a giveaway. You do know that FrontPage is very much
IE-centric, yes? ;-)
--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support
Restorm
much any more, and wouldn't use it at all if the incompetents at
Microsoft were able to include a "Navigation View" in Expression Web.
But you answered your own question: you haven't encountered the problem
because you don't use that function. As you can see from David Pyle's
posts, I'm not hallucinating.
Restorm
FrontPage, of course. But Firefox has NEVER been able to print tables
that span more than one page, so this isn't a W3 compatibility issue:
it's a long-standing bug, as David Pyles documented.
Restorm
The WWW is an evolving beast. There's no way billions of web pages
are going to magically be transformed to the latest compliance every
time new standards are created. Good tools are those that work in
reality, not in some idealized fantasy world of programmers.
Jay Garcia
--- Original Message ---
Yes, we know that but what I am alluding is that FrontPage
auto-generates code that is not compliant with most other browsers. I
use HomeSite a lot and everything I author is cross-browser compatible.
BTW: Your site is well constructed and pleasing to the eye. ;-)
Jay Garcia
--- Original Message ---
So true but as the beast evolves so must the dragon-slayer to compensate
for newly acquired tactics employed by the "beast".
David Pyles
David Pyles
<div>s they print fine.
Dave Pyles
John McGaw
Of course. Tables are not and never were a proper method of formatting.
They were used as such in the old days because it was mindlessly easy to do
so and there was no equally easy way to do it otherwise. Of course now
there is CSS which makes functional flexible formatting nearly as
mindlessly easy as tables used to. Yes, the transition is not as easy as it
should be but it is not really difficult either. I managed to do it and I
lay no claim to being a web designer. And I'm ancient to boot and don't
learn as well as I used to.
Terry R.
Regardless if it's used as a formatting tool, OR just for tabular data
(which tables are still suited for), the issue is the inability of FF to
print tables across multiple pages.
Don't blame it on web design.
Terry R.
--
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.
C A Upsdell
>>> The key word here is "Tables." If the paqges are laid out with CSS
>>> <div>s they print fine.
>>
>> formatting. They were used as such in the old days because it was
>> mindlessly easy to do so and there was no equally easy way to do it
>> otherwise. Of course now there is CSS which makes functional flexible
>> formatting nearly as mindlessly easy as tables used to. Yes, the
>> transition is not as easy as it should be but it is not really
>> difficult either. I managed to do it and I lay no claim to being a web
>> designer. And I'm ancient to boot and don't learn as well as I used to.
>
> Regardless if it's used as a formatting tool, OR just for tabular data
> (which tables are still suited for), the issue is the inability of FF to
> print tables across multiple pages.
>
> Don't blame it on web design.
I just checked a few of the sites I made which use tables. The only
problem I have with printing across pages is that CSS like
page-break-inside:avoid doesn't work. But everything prints.
Of course the fact that FF prints everything on *my* sites couldn't
possibly have anything to do with the fact that all *my* sites comply
with the standards, could it?
Robert
> For years, FF has only been able to print the first page of many
> websites, leaving the rest blank. This has been a known bug for all this
> time, yet I still have to switch to IE to print from my own website
> go to that sight in FF and do a "Print Preview", you'll see that all
> pages after the first are blank. This is how they come out of the
> printer, too. IE shows those pages in Preview mode, and prints them
> fine. How can the FF developers continue to ignore such a major bug?
> It's embarrassing when I recommend FF to my friends, and then later have
> to explain to them that they need to use IE to do something as simple as
> printing a web page.
I found this by doing a search for 'print tables' at
https://bugzilla.mozilla.org/query.cgi
Beauregard T. Shagnasty
> Terry R. wrote:
>> Regardless if it's used as a formatting tool, OR just for tabular
>> data (which tables are still suited for), the issue is the inability
>> of FF to print tables across multiple pages.
>>
>> Don't blame it on web design.
>
> I just checked a few of the sites I made which use tables. The only
> problem I have with printing across pages is that CSS like
> page-break-inside:avoid doesn't work. But everything prints.
>
> Of course the fact that FF prints everything on *my* sites couldn't
> possibly have anything to do with the fact that all *my* sites comply
> with the standards, could it?
Here's an experiment. Three pages with nested tables-for-layout, all
extending beyond one page, and constructed manually (with a lot of
cut'n'paste). There are no validation errors concerning the tables.
1 HTML 4.01 Strict
2 no DOCTYPE (quirks mode)
3 no DOCTYPE and with a random image to increase width
http://tekrider.net/usenet/nested.html
http://tekrider.net/usenet/nested2.html
http://tekrider.net/usenet/nested3.html
In my Firefox 3.0.14 (Ubuntu 8.04/GNOME), the Print Preview shows
correctly for all three pages. I don't have a Windows PC handy to test.
How do your views look?
David Pyles
Restorm
Restorm
better-off creating a new compliant site from scratch?
David Pyles
don't keep all of these newsgroup threads, so I no longer have the link.
Dave Pyles
David Pyles
button too soon.
Dave Pyles
C A Upsdell
No problem with FF 3.5 on Windows XP. Which is consistent with my sites.
propman
FF 3.5.3 here.....in all 3 examples Print Preview shows all pages. Might
want to run a spell checker on that lot though. ;-)
Michael Iannantuoni
> For years, FF has only been able to print the first page of many
> websites, leaving the rest blank. This has been a known bug for all
> this time, yet I still have to switch to IE to print from my own
> website (such as
> http://www.resolutionfund.com/Seminars-Rewealth.html). If you go to
> that sight in FF and do a "Print Preview", you'll see that all pages
> after the first are blank. This is how they come out of the printer,
> too. IE shows those pages in Preview mode, and prints them fine. How
> can the FF developers continue to ignore such a major bug? It's
> embarrassing when I recommend FF to my friends, and then later have to
> explain to them that they need to use IE to do something as simple as
> printing a web page.
Restorm
(and like Expression Web doesn't)? In other words, does it let you see
your entire site structure graphically (like a org chart), and drag a
page from under one page to another?
C A Upsdell
> I agree that my website is out of date, Beauregard, but IE prints it
> properly and FF doesn't...it's as simple as that.
Actually, it is NOT as simple as that. IE does not print it properly:
at best it APPEARS to print it as you EXPECT.
The fundamental problem is that the code is badly broken, with many HTML
and CSS errors.
When the HTML is invalid, the standards do not say what browsers should
do, so different browsers are free to do different things. IE tends to
try to guess what was intended, and when it guesses right, people are
happy and say that that IE does it properly ... but it is not *proper*,
it is just *as expected*.
When the CSS is invalid, the standards say that the invalid CSS should
be ignored, so different browsers SHOULD act similarly with invalid CSS.
But again IE tries to guess what was intended, and again when IE guesses
right, people are happy and say that IE does it properly ... but it does
not.
For example, the CSS for your page has many dumb errors, like this:
font-size: 3;
This is invalid, because no units are specified: units are required
unless the value is zero. Browsers are supposed to ignore invalid CSS
like this, but IE tends to guess that the units are 'px' when the units
are omitted.
The bottom line here is that you cannot expect browsers to behave
similarly unless the code is valid: when the code is invalid, all bets
are off.
Of course, valid code does not guarantee that the browsers will do it
right: older versions of IE often violated the standards, and all
browsers have bugs and limitations. But valid code is essential for a
browser to do it right. If you fix the code, and FF still does it
wrong, then you have a right to complain about FF. If you don't fix the
code, you have no right to complain.
Chris Ilias
> Restorm wrote:
>> I agree that my website is out of date, Beauregard, but IE prints it
>> properly and FF doesn't...it's as simple as that.
>
> The fundamental problem is that the code is badly broken, with many HTML
> and CSS errors.
Sometimes it is a Firefox bug. It's just a matter of investigating each
issue, rather than jumping to conclusions.
To Restorm,
Restorm, I don't see any question in your original post. What exactly
was the purpose of starting this thread? I think it would help everyone
help you we had a clearer picture of what you wanted to accomplish by
posting here.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Keeper of the Knowledge Base: <https://support.mozilla.com/kb/>
C A Upsdell
> On 09-10-18 4:45 PM, C A Upsdell wrote:
>> Restorm wrote:
>>> I agree that my website is out of date, Beauregard, but IE prints it
>>> properly and FF doesn't...it's as simple as that.
> <snip>
>>
>> The fundamental problem is that the code is badly broken, with many HTML
>> and CSS errors.
>
> Sometimes it is a Firefox bug. It's just a matter of investigating each
> issue, rather than jumping to conclusions.
Sometimes it is. But fix the errors first. Garbage in, garbage out.
Beauregard T. Shagnasty
[Shagnasty wrote:]
>> http://tekrider.net/usenet/nested.html
>> http://tekrider.net/usenet/nested2.html
>> http://tekrider.net/usenet/nested3.html
> FF 3.5.3 here.....in all 3 examples Print Preview shows all pages.
> Might want to run a spell checker on that lot though. ;-)
Muh speel chucker mest bee brocken?
Aside: For anyone confused by the text,
Google up: lorum ipsum generator
So, according to propman and C A Upsdell (and me), there is no problem
of Firefox unable to handle tables longer than a page. The
printing/preview problem with the OP's page must be something else.
Other than the HTML errors, the CSS errors, the incomplete DOCTYPE, and
the FrontPage MSTheme stuff, I don't know what it is.
Oh, I also saw this in the Response Headers of the OP's page:
Server: Microsoft-IIS/5.0
MicrosoftOfficeWebServer: 5.0_Pub <--- ???
and don't know if that is significant or not.
C A Upsdell
> So, according to propman and C A Upsdell (and me), there is no problem
Not quite. I don't assert that there are never problems with valid
code: FF has bugs, as we all know. All I say is that (a) problems are
fewer with valid code, and (b) the OP's code is not valid. The OP could
fix the code and find that the specific problem which plagues him is due
to an FF bug instead: but IMO fixing the code is step 1.
Jay Garcia
--- Original Message ---
> On 09-10-18 4:45 PM, C A Upsdell wrote:
>> Restorm wrote:
>>> I agree that my website is out of date, Beauregard, but IE prints it
>>> properly and FF doesn't...it's as simple as that.
> <snip>
>>
>> The fundamental problem is that the code is badly broken, with many HTML
>> and CSS errors.
>
>
> Sometimes it is a Firefox bug. It's just a matter of investigating each
> issue, rather than jumping to conclusions.
>
> To Restorm,
> Restorm, I don't see any question in your original post. What exactly
> was the purpose of starting this thread? I think it would help everyone
> help you we had a clearer picture of what you wanted to accomplish by
> posting here.
>
The subject contains the question followed by "How can the FF developers
continue to ignore such a major bug?" in the body text. Both are valid
questions as long as we don't get into OT discussion about whose browser
is best and so on ad nauseum. Good discussion if allowed to proceed on
course.
Beauregard T. Shagnasty
> For years, FF has only been able to print the first page of many
> websites, leaving the rest blank. ...
I have found what is causing (or at least I think I have) the "prints
only first page" problem of your proffered case.
On your page:
http://www.resolutionfund.com/Seminars-Rewealth.html
there are about a half-dozen places where the inline HTML styling uses
the attribute: height="100%"
One of those places is on a <table> tag, the rest are on select <td>
tags.
Remove those and the print preview is normal, with all pages showing up.
I had first removed the errant </ul> on or about line 630 (beginning of
line), but that didn't help.
</ul></li></ul></li></ul></td>
...^^^^^
Here is a copy of your page (sans images) with all the height="100%"
removed:
http://tekrider.net/usenet/rewealth.html
I don't notice any change in the browser display of the page with the
height missing.
I also added some random height="100%" to a test page:
http://tekrider.net/usenet/nested2a.html
and this didn't change the display, but did mess up the printing; it
actually expanded the printing from 4 pages to 9 pages. :-/
So then. The validator reports use of height="100%" as an error, albeit
thinks only the case of the word is at fault. It appears that Firefox
style-rendering *for printing* may have a problem with that attribute.
It also appears that it is *not* because tables themselves extend beyond
one page.
Who wants to notify the Firefox developers?
David McRitchie
Anybody can file a bug, but should also check if it is specifically already
filed. .
Some others, yours perhaps into a new bug since you have a specific cause
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=printing%20first%20page%20only
adding the word height to the above gets not results; however, I think
But is is probably already be covered in one of these
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=printing%20height
Beauregard T. Shagnasty
> Some others, yours perhaps into a new bug since you have a specific cause
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=printing%20first%20page%20only
> adding the word height to the above gets not results; however, I think
> But is is probably already be covered in one of these
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=printing%20height
It seems that bug 435830 has an example page http://www.papanews.it/
with the same problem, as it uses height="100%". (page has music) It
also uses:
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
Bug 424145 has an example page, too, but is currently unreachable.
I don't have an account there. Why don't you add a new bug, explaining
that the height attribute seems to be the root cause?
Peter Lawson
>
> Restorm wrote:
>
> > > For years, FF has only been able to print the first page of many
> > > websites, leaving the rest blank. ...
>
> I have found what is causing (or at least I think I have) the "prints
> only first page" problem of your proffered case.
>
> On your page:
> http://www.resolutionfund.com/Seminars-Rewealth.html
> there are about a half-dozen places where the inline HTML styling uses
> the attribute: height="100%"
>
This is wonderful detective work! Here is another example of a page
containing 'height="100%"' which only prints the first page
http://www.capetown.gov.za/en/electricity/tariffs/Pages/default.aspx
What function is the attribute *intended* to perform?
--
Peter Lawson
Cape Town: 021-797-4493
France 06 18 28 96 43
Restorm
attributes fixed the problem. Thank you very much for all the time you
put into this: it's been plaguing me for years. I'm not quite clear
though whether this is a FrontPage problem, a FF problem, or both.
Restorm
> On 09-10-18 4:45 PM, C A Upsdell wrote:
>> Restorm wrote:
>>> I agree that my website is out of date, Beauregard, but IE prints it
>>> properly and FF doesn't...it's as simple as that.
> <snip>
>>
>> The fundamental problem is that the code is badly broken, with many HTML
>> and CSS errors.
>
>
> Sometimes it is a Firefox bug. It's just a matter of investigating each
> issue, rather than jumping to conclusions.
>
> To Restorm,
> Restorm, I don't see any question in your original post. What exactly
> was the purpose of starting this thread? I think it would help everyone
> help you we had a clearer picture of what you wanted to accomplish by
> posting here.
>
has had no problem perceiving that my problem is that FF only prints the
first page of such sites, and leaves the following pages blank.
Granted, I could have been more concise, but the problem seems to be
clearly stated.
Beauregard T. Shagnasty
> Beauregard T. Shagnasty wrote:
>> Restorm wrote:
>>> For years, FF has only been able to print the first page of many
>>> websites, leaving the rest blank. ...
>>
>> I have found what is causing (or at least I think I have) the
>> "prints only first page" problem of your proffered case.
>>
>> On your page: http://www.resolutionfund.com/Seminars-Rewealth.html
>> there are about a half-dozen places where the inline HTML styling
>> uses the attribute: height="100%" [snip]
>
> You're absolutely right, Beauregard! Removing all the height="100%"
> attributes fixed the problem. Thank you very much for all the time
> you put into this: it's been plaguing me for years. I'm not quite
> clear though whether this is a FrontPage problem, a FF problem, or
> both.
You're welcome.
I knew there had to be some particular reason why your page (and similar
other ones) would not print beyond page 1, and I knew it wasn't because
tables extended past one page - as I've numerous pages with long tables
(for data, not presentation).
It's not FrontPage at fault^1, because it's just as easy to manually add
that height attribute to hand-coded pages. It appears to be a Firefox
problem when the print engine encounters it.
I also have Mozilla SeaMonkey (1.1.17) installed here, and the print
preview is fine, so it is just Firefox.
[1. That was hard to say... <g>]
Beauregard T. Shagnasty
> Beauregard T. Shagnasty wrote:
>> the attribute: height="100%"
>
> This is wonderful detective work! Here is another example of a page
> containing 'height="100%"' which only prints the first page
>
> http://www.capetown.gov.za/en/electricity/tariffs/Pages/default.aspx
Heh, that is a page with some convoluted code, eh?
<meta name="GENERATOR" content="Microsoft SharePoint" />
..and two DOCTYPEs. All bets are off! "598 Errors" when XHTML
Transitional is forced, as it seems to be the one they want.
> What function is the attribute *intended* to perform?
Well, I suspect the authors want the table or td to vertically fill the
viewport. Possibly useful for cells with a very small amount of content.
I have never used it, even in the bad old last-millennium style of
writing. Today, CSS should be used. However, authors using WYSIWYG tools
don't have much control, do they?
Restorm
FrontPage problem. You'll be lucky if you don't get death threats from
some other members of this forum...
Chris Ilias
> Chris Ilias wrote:
>
>> To Restorm,
>> Restorm, I don't see any question in your original post. What exactly
>> was the purpose of starting this thread? I think it would help
>> everyone help you we had a clearer picture of what you wanted to
>> accomplish by posting here.
>
> Hi, Chris. I'm confused by your comment. Everyone else in this thread
> has had no problem perceiving that my problem is that FF only prints the
> first page of such sites, and leaves the following pages blank. Granted,
> I could have been more concise, but the problem seems to be clearly stated.
Are you looking for a workaround?
Are you looking for help on how to code the site, so that Firefox prints
it correctly?
Are you reporting a bug (or just making sure the bug is reported)?
Are you asking where printing stands in terms of development priorities?
Are you just voicing a complaint?
Restorm
> On 09-10-20 7:26 AM, Restorm wrote:
>> Chris Ilias wrote:
>>
>>> To Restorm,
>>> Restorm, I don't see any question in your original post. What exactly
>>> was the purpose of starting this thread? I think it would help
>>> everyone help you we had a clearer picture of what you wanted to
>>> accomplish by posting here.
>>
>> Hi, Chris. I'm confused by your comment. Everyone else in this thread
>> has had no problem perceiving that my problem is that FF only prints the
>> first page of such sites, and leaves the following pages blank. Granted,
>> I could have been more concise, but the problem seems to be clearly
>> stated.
>
> Are you looking for a workaround?
> Are you looking for help on how to code the site, so that Firefox prints
> it correctly?
> Are you reporting a bug (or just making sure the bug is reported)?
> Are you asking where printing stands in terms of development priorities?
> Are you just voicing a complaint?
>
1. The workaround is obviously using IE (as I explained).
2. No: If IE can do it, FF should be able to do it.
3. Yes: if that's what it is (which it obviously is).
4. If you want me to, I will.
5. Obviously.
Thanks for being so fascinated with my motivations, Chris.
Want to know my favorite color, too?
Terry R.
Putting the moderator in his place....Priceless.
follow up set to mozilla.general
Terry R.
--
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.
C A Upsdell
>> Are you looking for a workaround?
>> Are you looking for help on how to code the site, so that Firefox
>> prints it correctly?
>> Are you reporting a bug (or just making sure the bug is reported)?
>> Are you asking where printing stands in terms of development priorities?
>> Are you just voicing a complaint?
>>
> To answer each of your 5 questions in order:
> 1. The workaround is obviously using IE (as I explained).
> 2. No: If IE can do it, FF should be able to do it.
> 3. Yes: if that's what it is (which it obviously is).
> 4. If you want me to, I will.
> 5. Obviously.
1. Using IE may be the correct workaround when the page is one which
you do not create. But if you create the page, the obvious first step
is, as I have said before, to fix the damn code.
2. If IE handles broken code in a certain way, FF should do exactly the
same? FF could only do that if if replicates every behaviour IE has,
including all the IE bugs, standards violations, and security defects.
Does that sound like a reasonable thing to expect?
3. It is not clear that it is a bug. Fix the damn code and then see if
the problem persists before you make this assertion.
Restorm
FF cannot handle the attribute height="100%". That's antiquated code,
but it's not "bad code", nor is it broken. FF should be able to print
properly despite its presence. Now, prepare to change your underwear,
as the following Good News will, no doubt, give you an orgasm of
delight: I removed every instance of that attribute from the site (all
328 of them), and it prints fine.
Ron Hunter
I probably shouldn't dip my oar into these waters, but this is getting a
bit ridiculous. What you are saying is that because IE ignores
standards, then Firefox should also. That's like saying that because
radical Islamics strap explosives to innocents, we should do the same
thing. NO. Firefox should work according to standards, and I see NO
evidence from your posts that the websites you have problems with are
coded according to standards. We all know it is possible to code
things that will ONLY work on IE, but that doesn't mean Firefox should
ignore standards as Microsoft often does.
I'm done with this thread.
Terry R.
Probably shouldn't have.
If you would have read what BTS wrote yesterday, you'd see it's beyond
your usual, "...like saying..." blabber.
"It appears that Firefox style-rendering *for printing* may have a
problem with that attribute. It also appears that it is *not* because
tables themselves extend beyond one page."
follow-up set to mozilla.general
Beauregard T. Shagnasty
> I removed every instance of that attribute from the site (all
> 328 of them), and it prints fine.
..hopefully with a global find and replace, eh? :-)
Glad you got it sorted.
C A Upsdell
> C A Upsdell wrote:
> If you had read the thread, you would see that Beauregard has found that
> FF cannot handle the attribute height="100%". That's antiquated code,
> but it's not "bad code", nor is it broken. FF should be able to print
> properly despite its presence.
Sigh. If you bother to run the page through the W3C validators, you
will see that the code is indeed broken: though there are fewer errors
now, I think, than a few days ago. It is good that you fixed your
immediate problem, but so long as your code is broken, you will be
vulnerable to undesirable browser behaviours.
Chris Ilias
Okay, it's apparent from your answer that you just wanted to vent your
complaint to developers.
As I told Lion Irons while back, this is user support newsgroup, not a
feedback newsgroup. Unless you are actually looking for help with
Firefox, posting complaints here will not do much good (and in some
cases, just start a flame war).
The most effective way to report a bug, is to file it via
bugzilla.mozilla.org. For instructions, see
<https://developer.mozilla.org/en/Bug_writing_guidelines>.
If there is already a bug report filed for the issue you are complaining
about, you can add your vote to the bug.
If you don't want to use bugzilla, you can always use
<http://feedback.mozilla.org/>. More devs read that feedack, than read
the posts here.
Anywise, thanks for your feedback.
Restorm
> Restorm wrote:
>
>> I removed every instance of that attribute from the site (all
>> 328 of them), and it prints fine.
>
> ..hopefully with a global find and replace, eh? :-)
>
> Glad you got it sorted.
>
Restorm
wasn't broken, so FF should have been able to print properly without my
having to remove it.
Restorm
compatibility with pre-W3 days is a valuable--nay, NECESSARY--trait, and
FF should have it. Lack of desire to maintain backwards compatibility
has always been on of the hallmarks of elitist programmers, who think
users have a responsibility to keep up with the latest and greatest.
Restorm
you'd like the dialog here to be rigidly-engineered to inhuman standards
of perfection, but this forum served its real-world purpose: a fellow
user (Beauregard) identified a bug in FF, and another user (David Pyles)
let me know I could safely delete the code that FF wasn't handling
properly. Problem solved...even though it violated the Sacred Laws of
Chris.
Christian Riechers
You've got your problem solved, good for you. To also help others
getting a FF bug fixed, I think it would be fair enough to make a little
effort and report a bug in bugzilla, or search for an existing bug
there, add additional information, or simply vote for it. This has got
nothing to do with the 'Sacred Laws' of a group moderator.
--
Christian
Restorm
is not actively involved in any of this development. I've tried it a few
times and found it to be more trouble than it was worth. There are
people who have been involved in this thread who probably use Bugzilla
often enough that making such a report would be quick and easy. I've
done my part in bringing the bug to light. Chris could reported it in
half the time he's spent reprimanding me for my non-compliant style of
communication.
David Pyles
Jay Garcia
--- Original Message ---
> Give it up, guys. -Dave Pyles
Amen!! Problem was solved.
--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support
Chris Ilias
> Reporting a bug via Bugzilla is no small effort for someone like me, who
> is not actively involved in any of this development. I've tried it a few
> times and found it to be more trouble than it was worth.
Well heck, I can help you learn bugzilla! :-) There's also the
mozilla.dev.quality newsgroup, where the quality assurance people can
help you. There may be some stuff on quality.mozilla.org. There is a
greater Mozilla community beyond this newsgroup, that everyone can make
use of.
If you are not sure whether or not the problem you are having is a bug,
you can report it as unconfirmed.
I've set replies to this post to go to mozilla.dev.quality.
Restorm
propman
Heh! Just a couple of waskerly wabbits...... ;-)
Mark Aitchison
> Reporting a bug via Bugzilla is no small effort for someone like me...
I agree, and I can see that (despite several official forums to discuss FF and
Thunderbird bugs) the whole bug reporting/discussion/support system does not do
particularly well in a few important areas:
1. Some of the worst bugs seem to go unsolved for a long time, and I suspect (from
recent discussions) it is more a lack of awareness than lack of time on the part of
developers. Is there a generally recognised "top ten" bugs list?
2. It is hard for users to tell whether the problems they have are a "known bug"
without asking questions on a forum like this, and getting a bit of flack sometimes as
well as having to explain problems that should be well known.
3. There seems to be little effort made to encourage web developers to watch out for
some of the most annoying problems in their site designs... often it can be genuine
faults in the html (that the latest IE gets around) rather than faults in FF, but the two
amount to the same thing for users of FF. So there should be a well-publicised "top ten
mistakes to avoid in websites" plus an automated test, a little like bobby, that anyone
can point at a doubtful website and it explains in plain language that users can
understand "this site has errors that FF and any browser following teh HTML standard will
have problems with" or "this site doesn't technically break any HTML rules, but it won't
print nicely", as well as detailed explanations website developers can act upon.
4. Overall, there needs to be an easier "middle step" between wordy discussions of a
problem that seems to be a bug, and the daunting official bug report process. It could
be a website people can go to which automatically records their browser version to make
life easy, or an add-on to FF itself, and should let users specify a web page they are
having problems with and the general nature of the problem (some error when trying to
display; parts of the page missing; displays okay but does not print; cosmetic problems;
etc). It may even allow a few sites to be listed that all exhibit the same problems, and
should allow a few extra details to be given, then the system checks the site for
features that relate to (at least some of) the known bugs and then does one of three things:
a. say what known bug(s) this is likely to be caused by, and provide links to relevant
bugzilla pages and to forums where it has been discussed and possibly a workaround suggested;
b. ask for contact details and says that somebody will have a look at it, and if it is
reproducible then an official bug report can be made easily after it has been checked;
c. explain the web page has HTML errors, or it is a site marked as spam or blocked in
some way, so it will not be passed on to be looked at by an expert.
And, FWIW, I agree with others that printing in FF (over many versions, including
Shiretoko) has been very problematic for many pages, not just a few. It includes pages
that preview okay but print badly (I don't think anyone mentioned that) and pages that
display nicely but previews split the contents (not frames) over several pages, and if I
print the one page of the preview that seems to have what I want then it is likely to be
different contents that will be printed. The user interface for printing could be much
better too (I could even produce something to show what it should be like, if anyone is
interested). Other major problems for me:
* h-u-g-e memory usage problems
* can only look at a .pdf a few times (might be Linux-specific) before FF has to be
restarted
* actions ("open with") for downloaded files not helpful
* add-ons rarely signed; hard to be confident of safety of even the most popular ones
* various differences between IE and FF, e.g. in table handling, that change layout and
readability.
Mark