FF 19 - Alters the PDF handler (to Mozilla's)

[VanguardLH]

Prior: Firefox 18.0.1
Now: Firefox 19.0
OS: Windows XP Pro SP-3

In the past, Firefox would use the PDFxchange plug-in (installed when I
installed PDFxchange Viewer) to display PDFs inside of Firefox (or
outside in the PDFxchange app if configured that way). Now after
upgrading to Firefox 19.0, I noticed PDFs were loading inside of Firefox
(as before) but now with a dark gray border and LOTS of functionality
missing. This is Mozilla's PDF viewer. Tis Crummy. I want PDFxchange.

I first checked to see if Mozilla decided to include an inbuilt plug-in,
like does Chrome, that I had to disable to instead use a different PDF
plug-in. Nope, no plug-in is listed for Mozilla's PDF handler. After
awhile, and after getting pestered by this several times of seeing
Mozilla's PDF handler showing the doc instead of PDFxchange, I remember
about the Applications settings in Firefox, which are at:

Tools -> Options -> Applications

For PDFs, I see that FF 19 has added "Preview in Firefox". It wasn't
how I had Firefox configured before. I had Firefox using the PDFxchange
plug-in to handle PDFs. Then I upgraded to FF 19 afterwhich I got stuck
using Mozilla's PDF viewer. When Mozilla added this PDF viewer in v19,
they should not have changed the existing configuration for what the
user already configred as the PDF handler. Do the upgrade but leave my
settings be!!! Use defaults when adding NEW settings that obviously
weren't available before for the user to modify.

Hmm, so it is new in v19:
http://www.webmonkey.com/2013/02/firefox-19-brings-built-in-pdf-viewer-faster-startup-times/

Okay, but that doesn't mean Mozilla should phuck with my existing
settings if they are still viable (defined) in the new version. Where's
my shotgun. Looks like it's time to forgetfully load a shell and then
"clean with an accidental discharge" near a Mozillian.

[WaltS]

So, click on Portable Document Format (PDF), and change "Preview in
Firefox" under Action, to the item of your choice in the drop-down list.

I will be happy when Firefox is plugin free.

Don't hurt yourself. As a user of Mozilla products, you are a Mozillian.

--
Fedora 18.0 (64-bit) KDE 4.9.5
Thunderbird Release

[kes]

Eh... There is only one real choice there:
- 'Preview in Firefox'
- 'Always ask'
- 'Save file'

I cannot see my 'Adobe Acrobat plugin' nor the 'PDFXchange' plugin.

(Adobe plugin is essential for me for one web I use, for work. Otherwise
I prefer PDFXchange.)

[Ron Hunter]

If you don't want to use the built-in PDF viewer, then when it comes up,
look at the top of the window, on the right, and choose 'Options'. They
click the 'open with' and select the viewer of your choice that you have
installed, and click the last box in the dialog, and click OK. Done.

[WaltS]

Sorry, don't use Windows, don't have any PDF plugins, but I can see my
systems PDF application as one of my choices, along with the three you
mentioned, and a "Use other... option.

[EE]

I switched the setting in Applications back to Always Ask. It works
fine for me. If I set it to load, it uses the helper application I set up.

[VanguardLH]

WaltS wrote:

> VanguardLH wrote:
>
>> In the past, Firefox would use the PDFxchange plug-in (installed when I
>> installed PDFxchange Viewer) to display PDFs inside of Firefox (or
>> outside in the PDFxchange app if configured that way). Now after
>> upgrading to Firefox 19.0, I noticed PDFs were loading inside of Firefox
>> (as before) but now with a dark gray border and LOTS of functionality
>> missing. This is Mozilla's PDF viewer. Tis Crummy. I want PDFxchange.
>

> So, click on Portable Document Format (PDF), and change "Preview in
> Firefox" under Action, to the item of your choice in the drop-down list.

As stated, I *did* do that before. I picked the PDFxchange plug-in as
my preference before. The installation of FF 19 *changed* that
preference. That last sentence "I want PDFxchange" should have been "I
*had* PDFxchange before, still wanted it after the v19 update."

If Mozilla is going to alter user-configured preference settings on
updates then I'll have to go research on how to export or save my
settings so I can step back on them when Mozilla steps on them.

[VanguardLH]

So anytime Mozilla changes the user-defined preferences then user just
go change them back, is that what you're recommending? If user settings
aren't going to stick, even with updates, then why bother setting them?

So how many more times am I going to have to change back to my prior
settings? Mozilla changed them during this update. Imagine the major
pain in the butt if Mozilla goes modifying all the other about:config
and app association settings that I've made before. Users don't spend
time researching the tweaks only to have Mozilla throw them away.

[VanguardLH]

I switched back to using my choice (PDFxchange Viewer) that I had
selected before. The point is that *I had to switch back*. Mozilla
should not be discarding user-configured settings. I found their update
changed this setting. How many other tweaks might they have altered?

[Jay Garcia]

On 27.02.2013 07:26, VanguardLH wrote:

Is it possible maybe that FF 19 thought that PDFexchange was not
compatible for some reason and reset back to the default plugin? Dunno,
but may be the case.


--
Jay Garcia - www.ufaq.org - Netscape - Firefox - SeaMonkey - Thunderbird
Mozilla Contribute Coordinator Team - www.mozilla.org/contribute/
Mozilla Mozillian Member - www.mozillians.org
Mozilla Contributor Member - www.mozilla.org/credits/

[WaltS]

As many times as required, with any application. IMHO

Every user should review preference settings every time they
install a new application before using it. Play, see what changes occur,
and find out how they like it configured. Review them after every
update, because *surprise* they do change, new preferences added, old
removed.

Very few users tweak, they just use it.

<https://blog.mozilla.org/imelven/2013/02/25/how-often-do-firefox-users-change-their-default-preferences/>

In case anyone misses the link in that blog post.

<http://monica-at-mozilla.blogspot.com/2013/02/writing-for-98.html>

Followup-To: mozilla.general

[»Q«]

On Wed, 27 Feb 2013 07:27:32 -0600
VanguardLH <V...@nguard.LH> wrote:

> I switched back to using my choice (PDFxchange Viewer) that I had
> selected before. The point is that *I had to switch back*. Mozilla
> should not be discarding user-configured settings. I found their
> update changed this setting. How many other tweaks might they have
> altered?

They introduced a new browser feature and enabled it by default; this
will happen occasionally. They won't arbitrarily change your tweaks
though, and new features are mentioned in the release notes so you can
spot them easily.

[VanguardLH]

A very poor attitude (by Mozilla or any software vendor), if true. If
an update is going to change settings then those settings should never
be exposed to users in the first place whether in a graphical config UI
or in some non-informative text listing (e.g., about:config). If you
don't want your users to tweak your product then don't let them. If you
are going to allow them to tweak your product then don't undo their
efforts. Settings, preferences, and other config exposed to the user
are there for a reason: to permit customization. Updates should not be
discarding that customization.

Imagine how many users would get pissed off and start looking for
alternatives if updates to their word process discarded their templates,
paragraph spacing, fonts, the words they added to the dictionary, or all
those other user-configurable settings. What would be the point of
defining rules in your firewall if they're just going to get discarded
on a later update.

Any program that is altering existing configuration is misbehaving.
Yes, new settings show up so obviously there were no old settings to
keep for those new ones. Yes, old settings go away so the user loses
that configurability in the program. But settings that existed before
that still exist after an update should ALL remain the same as they were
before; otherwise, just discard ALL settings and force users to start
ALL OVER with each new update. Punish your users for customizing your
product on their hosts. See how long your customers remain loyal to
your product when you decide to be so rude.

I don't know what other preferences or about:config settings might've
gotten changed. I experienced this one. Are you saying that every time
you get an update to Firefox that you actually go through your described
exercise to retest that your product's behavior is the same as before?
Hell, we don't even do that manually in Software QA. That's what
automated test tools are for to do all that regression testing. You
don't go through that entire exercise so don't be telling others they
should be going through it. Users don't don't do regression testing.
If something changed from the old behavior, especially for when their
settings have been discarded or altered, THAT is when users experience
that change. That's what happened to me. And despit what you claim,
that's just how you find out about the changed behavior, too.

By the way, I would change "very few users tweak" to "a low percentage
of users tweak". I certainly wouldn't want to be surrounded by an angry
mob with knives the size of which were Firefox users that tweak. Very
few Firefox users visit this forum, too. So you're talking about the
same low count of users visiting here that are also the low count of
users that tweak. In this community, that would mean there is a high
percentage of tweaking users here. Even for the drive-by users wanting
help just once and getting told to make a change in about:config, yep,
they've just become tweakers, too.

Sorry, but your advice is just as much a smack in the face of users as
Mozilla making changes to existing settings (that still exist after an
update). Mozilla: Slap, ha ha ha, we changed some settings. You: Slap,
ha ha ha, now go regression test the product to see what settings of
yours were changed. Neither is going to be tolerated by users.

This is the first time over several version of Firefox that I've been
nailed by Mozilla altering my settings. Of course, it really means that
this is the first time that I've *noticed* my settings got changed. I
can't tell you when Microsoft changed my Word settings because I never
noticed they did. CCleaner has retained my settings through countless
updates. If Acronis changed settings or altered my backups just
because I updated their True Image product, do you think I'd keep using
them? Every update would be a moving target.

So far, I've noticed this just once so I'm hoping it was just a glitch.
Yet that Mozilla just introduced their PDF Viewer in FF 19 and I just
experienced this preference getting changed after updating to FF 19 sure
makes them look linked. Hopefully Mozilla doesn't discard by
preferences or other settings in v19 or in later updates.

> Followup-To: mozilla.general

Rudeness ignored. I don't punch holes in threads or create new threads
without context. This is still an issue regarding Firefox and
mishandling of preferences by its update.

[VanguardLH]

»Q« wrote:

> VanguardLH wrote:
>
>> I switched back to using my choice (PDFxchange Viewer) that I had
>> selected before. The point is that *I had to switch back*. Mozilla
>> should not be discarding user-configured settings. I found their
>> update changed this setting. How many other tweaks might they have
>> altered?
>
> They introduced a new browser feature and enabled it by default; this
> will happen occasionally. They won't arbitrarily change your tweaks
> though, and new features are mentioned in the release notes so you can
> spot them easily.

They were so enthused with their underwhelming achievement to produce a
weak PDF viewer that they had to step on whatever users had already
deployed. Oh yay, oi vey <rolleyes>.

When I noticed the oddball PDF behavior, I looked at the release notes:

http://www.mozilla.org/en-US/mobile/19.0/releasenotes/

Mozilla's concept of "release notes" is not to *document* deletions,
additions, or changes in functionality (so it would apply against a
Functional Specification). It's just a list (aka changelog). All you
see mentioned as the full documentation regarding this new functionality
is "Built-in PDF viewer". Oh wow, how informative. I had to Google
search to find a non-Mozilla article describing the new feature.

The release notes don't document a changed or new feature. They just
list it. Then it's up to the user to figure out how to fix the
misbehaving program. I had previously played around with the PDF app
association so when I saw the wrong PDF viewer getting used then I
remembered about this app setting in Firefox. Other users won't be so
lucky. They'll get stuck with Mozilla's choice.

Because Mozilla chose to step on preferences changed by the user (i.e.,
on settings changed from their defaults), now I have to consider how to
best and easily save all setup before an update so I can step on Mozilla
after Mozilla steps on me. I hadn't before considered that I had to
protect myself from Mozilla.

[WaltS]

I don't see it as a support question any longer. Sorry you are unhappy
Mozilla forced it upon you. Not the first time, won't be the last.

I have been using the extension since version 0.1.0, released in
December of 2011, starting with Firefox 6.0. Maybe earlier.

<http://andreasgal.com/2011/06/15/pdf-js/>

I am quite happy it is now a feature, and I don't have to rely on a
plugin vulnerable to security problems.

It has come a long way, and I can change the Portable Document Format
(PDF) action in my Applications preference if I so chose.

[Chris Ilias]

On 2013-02-27 10:34 AM, VanguardLH wrote:
> WaltS wrote:
>

>> Followup-To: mozilla.general
>
> Rudeness ignored. I don't punch holes in threads or create new threads
> without context. This is still an issue regarding Firefox and
> mishandling of preferences by its update.

Hi VanguardLH,

Your posting address doesn't appear to be valid, so this warning is
being posted here.

In December, I explained to you why people sometimes move threads.
<https://groups.google.com/group/mozilla.support.firefox/msg/a1c5b8c6a565e77c>

I've also posted quite a few times, explaining that this is not the
place for discussing opinions about Firefox development.

I don't know if you forgot about the rules or chose to ignore them, but
it's clear that you're not trying to respect them. You can reread the
rules by visiting <http://www.mozilla.org/about/forums/etiquette.html>.

So hopefully you now understand why this discussion and a couple of
previous ones were moved to mozilla.general. It's important to remember
that the reason people subscribe to the Mozilla Support newsgroups or
mailing lists is for user support; and if they have to read through many
messages that are of no help in their use of the product, they're not
getting what they subscribed for.

If you do want to post an off-topic message, there a few things you can do:
* You can reply to the poster via private email
* You can suggest taking the discussion to a place where the discussion
would not be off-topic.
* You can force replies to be sent to the mozilla.general, where
off-topic discussion is allowed. To do that, just set the Followup-To
header on your post. [Demonstration video:
<http://ilias.ca/flashback/tb2-followup.html>]


I've set replies to go to my email address, rather than the newsgroup.
If you'd like to reply to this message, please email me with a valid
return address, thanks.

--
Chris Ilias <http://ilias.ca>
Mailing list/Newsgroup moderator

[Ron Hunter]

They want users to see the new feature, and they make it very easy to
revert. I have no problem with it.

[Ron Hunter]

Bottom line: Users who don't want changes should turn off updating,
period. No updates, no changes. Simple.

[»Q«]

On Wed, 27 Feb 2013 10:24:50 -0600
VanguardLH <V...@nguard.LH> wrote:

[snip all]

This support newsgroup is an inappropriate place for posting opinions
about how Mozilla should conduct themselves. Furthermore, posting your
opinions here will never result in Mozilla considering your opinions.

If you just want to jaw about them, without trying to bring them to
Mozilla's attention, the mozilla.general newsgroup is the place.

If you want Mozilla to consider your ideas, there's "Help » Submit
Feedback", there's <https://bugzilla.mozilla.org/>, and there's the
newsgroup for Firefox development, mozilla.dev.apps.firefox . There
are also some channels on irc.mozilla.org, but I couldn't tell you
which ones are best for getting somebody within Mozilla to notice what
you have to say.

[VanguardLH]

Yeah, we wouldn't want to have a thread here for other users suddenly
encountering a switch in the PDF handler in Firefox.

[RussCA]

Pardon me, Jay, but FF 19 does not "think". It only does what it was
coded to do. I was bothered by the same "gottcha". When I viewed a
PDF, I couldn't do anything. I checked the settings, and found
EVERYTHING I had changed to Adobe Reader had changed. My question is,
why, and will it happen on the next release?

OTOH, why change the way that FF handles PDF files? What is so sacred
about Mozilla always doing everything for everyone?

The issue is that FF changes user's settings, apparently for no other
reason than to force something down our throats that we just might not
want. I bet everyone at Mozilla constantly sings "I Did It My Way!"

[RussCA]

I humbly beg your pardon, but I for one was unaware that FF had
automatically upgraded to version 19.0. This is the result of
supposedly "seamless" upgrading. So are you advocating that users
disable automatic updates and occasionally check for new versions and
read the release notes? This seems like a step backwards to me. If
Mozilla truly wants "seamless updates", they they ought to have more
respect for their users.

As for reading the release notes to "spot" changes, I doubt that the
release notes for 19.0 state that the user's application setting for PDF
had changed. At best, the most reasonable way of handling this would be
for the application to explicitly warn users that such changes have
taken place. Even better would be to not force users to use modified
features. Instead, inform them after a "seamless" update that they have
new options.

[The Wanderer]

As I understand matters, the reasons for incorporating a PDF viewer into Firefox
include:

* Convenience, in that it means you don't *have* to have a separate PDF-viewing
program installed in order to access PDFs.

* "Keeping up with the Joneses", in that I think at least one other notable
browser already has one.

* Security, in that the most common PDF viewer (Adobe Reader) has known - and,
given that a random search today found news reports about one from within the
past 24 hours, possibly somewhat frequent - security holes; even if/when similar
holes are discovered in the Firefox PDF viewer, Mozilla will have the ability to
fix it themselves instead of waiting on Adobe, and it will be easier to deploy
the fix (via the normal Firefox update channels) than trying to get users to
install the updated Adobe Reader version.

Now, that said, I very probably agree that automatically overriding the user's
manually-set PDF-viewing plugin association is a Bad Thing. But the initial
"change [in[ the way that FF handles PDF files" itself is not a bad thing.

--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger

[»Q«]

That's incorrect. We wouldn't want a lot of *noise* in such thread
(or in any thread).

[crossposted, followup set to mozilla.general]

[Ron K.]

The Wanderer on 2/28/2013 9:18 AM, keyboarded a reply:

I am surprised by the argument that FF altered original PDF handling
prefs, Mine were not changed, except by addition of the Mozilla FF
internal handler when I reviewed My Options > Applications listing.

--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!

[VanguardLH]

The Wanderer wrote:

> As I understand matters, the reasons for incorporating a PDF viewer
> into Firefox include:
>
> * Convenience, in that it means you don't *have* to have a separate
> PDF-viewing program installed in order to access PDFs.

By now, and since Mozilla is catching r-e-a-l-l-y late, everyone that
was viewing PDFs obviously already had a PDF viewer installed. Think
about it: what would be the percent of Firefox users that did not
already have a PDF viewer app or plug-in already installed before FF 19
was released? Of that tiny percentage, if they didn't need a PDF viewer
before then why would they care now?

Chrome comes with its own internal PDF viewer. Well, guess who is the
biggest source of revenue to Mozilla. Yep, Google, so Mozilla followed
suit to incorporate a PDF viewer. Yet I don't remember how many times
users of Chrome would ask how to disable that crappy inbuilt PDF viewer
so they could use their choice. They'd install their choice but were
still stuck with the weak inbuilt PDF viewer because it would override
the user's choice. The user had to go modify Chrome's config to
override the override.

> * "Keeping up with the Joneses", in that I think at least one other notable
> browser already has one.

Yeah, really late, like waiting for the last runner in a marathon to
show up 6 hours late. If you are super late, sometimes it's better not
to show up at all. The party is over by the time you show up.

> * Security, ... (Adobe Reader) ...

Some of us realized that AR was not just insecure but the prime target
for attack (similar to the argument as to why malware targets Windows
more than *NIX). So we went with a less targeted PDF viewer and one
that had much better security options, like what to do about attachments
or launch actions inside a PDF, although Adobe is catching up.

Until tested over time, a "security" argument holds no water because it
is yet unknown and untested that Mozilla's solution is any more secure.
Just because it is new and hasn't yet accumulated any reported
vulnerabilities or security updates doesn't make it more secure. Since
Mozilla's PDF viewer is Javascript based, vulnerabilities in their
Javascript pass onto their PDF viewer, like the recently fixed FF 18 at
http://www.mozilla.org/security/announce/2013/mfsa2013-12.html.

"View PDF files in Firefox without downloading them"
http://support.mozilla.org/en-US/kb/view-pdf-files-firefox-without-downloading-them

This says the new built-in PDF viewer comes from pdf.js yet I can't find
this file on my computer. I suspect they rolled the code into something
else for Firefox. Isn't this just the Mozilla PDF add-on rolled into
Firefox?

https://addons.mozilla.org/en-us/firefox/addon/pdfjs/

https://github.com/mozilla/pdf.js/issues
(473 open issues, 2374 closed)
Look like this started June 2011.

http://www.pcworld.com/article/2025153/firefoxs-pdf-viewer-may-boost-security-by-boring-hackers.html
That article says my guess was right and the PDF.js project is what got
rolled into FF 19.

"Mozilla did not clarify whether this viewer will be used by default
even in cases when a third-party PDF viewing plug-in is installed."

Well, that's been resolved here. They do. Mozilla does make their PDF
viewer the default even when 3rd party PDF viewers are already installed
(and were selected as the PDF handler).

> Now, that said, I very probably agree that automatically overriding the user's
> manually-set PDF-viewing plugin association is a Bad Thing. But the initial
> "change [in[ the way that FF handles PDF files" itself is not a bad thing.

A side concern is that if Mozilla feels they can change the user's
preference any time they feel like it (I like RussCA's cute berate of
Mozilla singing "I did it my way") then what else might've they changed
that I haven't yet notice in past updates and what might they
arbitrarily change later.

I'm hoping this was a rare bad choice by one of their programmers and
this is not normally considered acceptable behavior. I'm hoping they
goofed this time by forcing a change rather than checking and only
changing if not set to the default.

As companies adopt FF 19, I suspect the volume of discontent (or perhaps
glee) will grow over Mozilla yanking away the prior PDF config. I'm
seeing more posts about users that come into work and suddenly PDFs are
not rendering properly, freezing up, no search results, showing inside
FF instead of opened in the PDF app, and other problems. They're
switching back to IE to get PDFs to work. I've already given a heads up
to our IT and helpdesk folks to prepare for this problem. I'm seeing
more noise about PDF.js from IT folks, like:

http://security.stackexchange.com/questions/31549/what-security-risks-does-firefox-19s-built-in-pdf-reader-pdf-js-bring

[VanguardLH]

Ron K. wrote:

> I am surprised by the argument that FF altered original PDF handling
> prefs, Mine were not changed, except by addition of the Mozilla FF
> internal handler when I reviewed My Options > Applications listing.

Which previously installed PDF viewer handler did you have in Firefox
(18 or whatever pre-19 version you had) when you updated to FF 19? It
might make a difference. Maybe whomever wrote the checking code was
familiar with Adobe Reader but not other PDF viewers.

Did you have Adobe Reader as your PDF viewer handler in Firefox before
updating to FF 19?

[VanguardLH]

RussCA wrote:

> �Q� wrote:
>
>> They introduced a new browser feature and enabled it by default; this
>> will happen occasionally. They won't arbitrarily change your tweaks
>> though, and new features are mentioned in the release notes so you can
>> spot them easily.
>
> I humbly beg your pardon, but I for one was unaware that FF had
> automatically upgraded to version 19.0. This is the result of
> supposedly "seamless" upgrading. So are you advocating that users
> disable automatic updates and occasionally check for new versions and
> read the release notes? This seems like a step backwards to me. If
> Mozilla truly wants "seamless updates", they they ought to have more
> respect for their users.
>
> As for reading the release notes to "spot" changes, I doubt that the
> release notes for 19.0 state that the user's application setting for PDF
> had changed. At best, the most reasonable way of handling this would be
> for the application to explicitly warn users that such changes have
> taken place. Even better would be to not force users to use modified
> features. Instead, inform them after a "seamless" update that they have
> new options.

Unlike release notes for enterprise-level applications where additions,
deletions, or changes to functionality are described fully including any
configuration changes or workarounds (because they are considered
incremental changes to later add to the Functional Specification for the
next major release), Mozilla's "release notes" is just a listing akin to
a changelog.

http://www.mozilla.org/en-US/firefox/19.0/releasenotes/
"Built-in PDF viewer"

That's all it says. Not even a link to:

http://support.mozilla.org/en-US/kb/view-pdf-files-firefox-without-downloading-them

I've never been impressed with their release notes. It's not a good
document. It's a terse list. It's like hearing an almost indistinct
alarm and then going hunting around for its source. With their release
notes, you might get a heads up on a change but then you'll have to go
hunting around to further research it. With real release notes, you sit
down and read it (because there *is* something there to read) BEFORE you
install that next version versus risk jumping into the fire and hope
you're flameproof.

How many users actually read the release notes (providing they can find
them)? It's not like the button to check for an update leads you to a
web page with the release notes so you can read it BEFORE choosing to
update. Notice the update button says "*Check* for update" but what it
actually does is "Perform update". Bad semantics.

I remember hearing or reading some car safety tip that says you should
walk around your car to check the tires are okay (no flats), if there
are open doors or trunk, or whatever you should check before you get in
and turn the ignition key. So how many drivers actually do that?
Similarly, how many users actually read the release notes before they
click on "Check for update" (which performs the update instead)? If
averaging the percentage number to a whole integer, would that manage to
get up to 1%? It's when they get burned that a /few/ will go read the
release notes as terse as they may be. More likely they'll come here,
go to forums, or use online searches to find out what the hell happened
and how to fix it.

If you did absolutely everything possible to protect yourself from bad
consequences in your daily routine, you'd have no time to live your
life. You'd be focused on the minutia instead of getting the major
stuff done.

Okay, so much for the daily sermon. So far, from the other posts or
reports that I've seen where users got nailed by the new PDF feature,
none have read the release notes before updating. That is *expected*
behavior by users.

[Ron K.]

VanguardLH on 2/28/2013 4:30 PM, keyboarded a reply:

> Ron K. wrote:
>
>> I am surprised by the argument that FF altered original PDF handling
>> prefs, Mine were not changed, except by addition of the Mozilla FF
>> internal handler when I reviewed My Options > Applications listing.
>
> Which previously installed PDF viewer handler did you have in Firefox
> (18 or whatever pre-19 version you had) when you updated to FF 19? It
> might make a difference. Maybe whomever wrote the checking code was
> familiar with Adobe Reader but not other PDF viewers.

This is a possibility. Would also depend on where FF looks to learn the
registered MIME association.

> Did you have Adobe Reader as your PDF viewer handler in Firefox before
> updating to FF 19?
>

Acrobat Reader being set as external helper has been my setting for
years. Better viewing space and it stays up when I close FF. Those
settings were unaffected by the update. When I found the new FF App, I
set it to Reader also and that has stuck. If it is not sticking for You,
it is a local problem I think.

[Ron K.]

VanguardLH on 2/28/2013 4:24 PM, keyboarded a reply:

> The Wanderer wrote:
>
>> As I understand matters, the reasons for incorporating a PDF viewer
>> into Firefox include:
>>
>> * Convenience, in that it means you don't *have* to have a separate
>> PDF-viewing program installed in order to access PDFs.
>

>

> This says the new built-in PDF viewer comes from pdf.js yet I can't find
> this file on my computer. I suspect they rolled the code into something
> else for Firefox. Isn't this just the Mozilla PDF add-on rolled into
> Firefox?
>

Mozilla rolls much of there JS into Omni.ja which is an archive format
file. All of the modules which were in the Components folder for years
are in the rollup.

[Jay Garcia]

Gee, thanks for reminding me.

> I was bothered by the same "gottcha". When I viewed a
> PDF, I couldn't do anything. I checked the settings, and found
> EVERYTHING I had changed to Adobe Reader had changed. My question is,
> why, and will it happen on the next release?
>
> OTOH, why change the way that FF handles PDF files? What is so sacred
> about Mozilla always doing everything for everyone?
>
> The issue is that FF changes user's settings, apparently for no other
> reason than to force something down our throats that we just might not
> want. I bet everyone at Mozilla constantly sings "I Did It My Way!"
>

Of course it doesn't "think" as you and I would but what was meant by
the term/word "think" is that what is coded in Firefox is set to
recognize certain applications as being compatible. If PDFExchange isn't
recognized or set as incompatible for whatever reason, then possibly the
settings reverted to default. Dunno, that's why I entered what I did as
a "maybe".

[Jay Garcia]

On 28.02.2013 07:23, RussCA wrote:

--- Original Message ---

If you feel like what you encountered is a bug then you have the right
and the opportunity to file one:

http://bugzilla.mozilla.org

Good luck, post the URL to your bug and we'll make sure to follow it.

[Jay Garcia]

On 28.02.2013 15:30, VanguardLH wrote:

--- Original Message ---

AR is my default and still is after upgrading to 19 and also still is
after upgrading 20 to 21 and 22. Must be some other glitch involved, dunno.

[Jay Garcia]

On 28.02.2013 16:06, VanguardLH wrote:

--- Original Message ---

> I remember hearing or reading some car safety tip that says you should
> walk around your car to check the tires are okay (no flats), if there
> are open doors or trunk, or whatever you should check before you get in
> and turn the ignition key. So how many drivers actually do that?

Actually nobody that I know of. But I DO walk aroung my airplane for
saftey checks, etc. But then again if something goes wrong I can't
simply pull over to the curb and fix it.

> Similarly, how many users actually read the release notes before they
> click on "Check for update" (which performs the update instead)?

Very few .. and that's why we see so many posts in these support groups
griping and complaining about "this doesn't work" or "it updated without
my permission" and a myriad of other issues and so on ad nauseum.

>If averaging the percentage number to a whole integer, would that manage to
> get up to 1%? It's when they get burned that a /few/ will go read the
> release notes as terse as they may be. More likely they'll come here,
> go to forums, or use online searches to find out what the hell happened
> and how to fix it.
>
> If you did absolutely everything possible to protect yourself from bad
> consequences in your daily routine, you'd have no time to live your
> life. You'd be focused on the minutia instead of getting the major
> stuff done.
>
> Okay, so much for the daily sermon. So far, from the other posts or
> reports that I've seen where users got nailed by the new PDF feature,
> none have read the release notes before updating. That is *expected*
> behavior by users.
>

RTFM rulez! :-)

[Jay Garcia]

On 28.02.2013 17:40, Ron K. wrote:

--- Original Message ---

> VanguardLH on 2/28/2013 4:30 PM, keyboarded a reply:
>> Ron K. wrote:
>>
>>> I am surprised by the argument that FF altered original PDF handling
>>> prefs, Mine were not changed, except by addition of the Mozilla FF
>>> internal handler when I reviewed My Options > Applications listing.
>>
>> Which previously installed PDF viewer handler did you have in Firefox
>> (18 or whatever pre-19 version you had) when you updated to FF 19? It
>> might make a difference. Maybe whomever wrote the checking code was
>> familiar with Adobe Reader but not other PDF viewers.
>
> This is a possibility. Would also depend on where FF looks to learn the
> registered MIME association.
>
>> Did you have Adobe Reader as your PDF viewer handler in Firefox before
>> updating to FF 19?
>>
>
> Acrobat Reader being set as external helper has been my setting for
> years. Better viewing space and it stays up when I close FF. Those
> settings were unaffected by the update. When I found the new FF App, I
> set it to Reader also and that has stuck. If it is not sticking for You,
> it is a local problem I think.
>

I hate "me too's" but .. me too!! My AR has maintained the default
throughout all FF upgrades thus far and even through the betas 20 thru
22 so far.

[Meriodoc Brandybuck]

Jay;

To RTFM, the manual has to first exist. There is no such animal as an up
to date manual for Firefox. The only things that I can find via a Google
search are different blogs and such that are a year to two or three
years old.

A far as the release notes they are a joke. Here is what the release
notes say about the PDF viewer: NEW Built-in PDF viewer. Is it a new
option? Is it set on by default(Yes it is), not even a brief description
of what it does.

With that kind of documentation you should not be surprised that there
are so many confused users asking questions. Even if they can find the
release notes and read them they give no useful information.

If you are going to tell us to Read The F*cking Manual, at least provide
a useful and up to date manual to read.

Regards
Keith

[VanguardLH]

Jay Garcia wrote:

> VanguardLH wrote:
>
>> Ron K. wrote:
>>
>>> I am surprised by the argument that FF altered original PDF handling
>>> prefs, Mine were not changed, except by addition of the Mozilla FF
>>> internal handler when I reviewed My Options > Applications listing.
>>
>> Which previously installed PDF viewer handler did you have in Firefox
>> (18 or whatever pre-19 version you had) when you updated to FF 19? It
>> might make a difference. Maybe whomever wrote the checking code was
>> familiar with Adobe Reader but not other PDF viewers.
>

> AR is my default and still is after upgrading to 19 and also still is
> after upgrading 20 to 21 and 22. Must be some other glitch involved, dunno.

That's why I asked. Could be the programmer that wrote the code to test
the state of the app association for the PDF handler only knows about
Adobe Reader (AR). If some other PDF viewer was selected, the code
doesn't understand that setting and reverts to a default (which is now
the PDF.js viewer from Mozilla).

So far, it looks like users of AR are keeping AR as their PDF viewer
after upgrading to FF 19. Users of non-AR viewers are getting screwed.
The code can recognize AR but not other PDF viewers. For example:

Change PDF_reader = Mozilla PDF.js
unless PDF_reader = Adobe Reader

That would change the PDF app assoc for everyone except AR users.

If PDF_reader = null then change PDF_reader = Mozilla PDF.js

That would change to Mozilla's PDF.js only if the PDF app association
had never been set or was at its default value (of no handler). If that
app association had been set to anything else then it would NOT get
changed to Mozilla's offering.

This is just a preliminary guess based on a very limited (just 2)
responses here. Time will tell if AR users don't have a problem but
everyone else does.

[Zube]

On Fri Mar 01 05:21:47 PM, VanguardLH wrote:

[Lots of snipping]

> Change PDF_reader = Mozilla PDF.js
> unless PDF_reader = Adobe Reader
>
> That would change the PDF app assoc for everyone except AR users.
>
> If PDF_reader = null then change PDF_reader = Mozilla PDF.js
>
> That would change to Mozilla's PDF.js only if the PDF app association
> had never been set or was at its default value (of no handler). If that
> app association had been set to anything else then it would NOT get
> changed to Mozilla's offering.
>
> This is just a preliminary guess based on a very limited (just 2)
> responses here. Time will tell if AR users don't have a problem but
> everyone else does.

Just another data point:

I had the Sumatra PDF viewer (portable) as mine and it was switched to
the built-in Mozilla one upon upgrading to FF 19.

Cheers,
Zube

[VanguardLH]

I did a search there on "pdf" and nothing that I saw describes this
problem. I'm currently reading their "bug writing guidelines" and doing
other research so I have some clue what to do after signing up and
writing a trouble ticket. I'll be a newb stumbling in a cave over there
but I want to have a flashlight when going in.

[Jay Garcia]

Doesn't appear as though the bug has been filed yet, so good luck. There
will be constructive comments after you file but one thing from years of
filing bugs, make it short and to the point. Grading a bug with an
anemometer is not advised. :-)

[»Q«]

On Fri, 01 Mar 2013 17:02:51 -0500
Meriodoc Brandybuck <meriodoc_...@yahoo.com> wrote:

> If you are going to tell us to Read The F*cking Manual, at least
> provide a useful and up to date manual to read.

<http://mzl.la/MyRa61>

HTH.

[Meriodoc Brandybuck]

Thank you for that informative article, I have bookmarked it and that
site for further investigation. My comments were aimed more at an
overall manual for Firefox. It is a very configurable and because of
that an extremely complex piece of software. I am as much a fan of hunt
and seek learning as the next person, but I find that having good,
updated documentation I can refer mark to and mark up as I please
invaluable. Again thank you for the link to the PDF reader.

Regards
Keith

[WaltS]

On 03/02/2013 03:06 AM, Meriodoc Brandybuck wrote:

Well, I don't think it is going to be fully complete, but here is one
person's attempt.

<http://www.nidelven-it.no/documentation/firefox/introduction-to-firefox>

Then there are Floss manuals.

<http://en.flossmanuals.net/firefox/index/>

You can also follow my feeble attempts at documenting new features in
mozilla.general when I think it warrants a post, like the most recent on
Firefox Health Report.

<https://groups.google.com/d/topic/mozilla.general/VFXNhKydBgE/discussion>


--
Fedora 18.0 (64-bit) KDE 4.9.5
Thunderbird Daily
If we burn in hell, do we freeze in heaven?

[Jay Garcia]

On 02.03.2013 02:06, Meriodoc Brandybuck wrote:

--- Original Message ---

Interested in Writing and Documentation?

Write Firefox Knowledge Base articles
http://support.mozilla.com/en-US/kb/improve-knowledge-base
Write Thunderbird Knowledge Base articles
http://support.mozillamessaging.com/en-US/kb/improve-knowledge-base
Help with Mozilla Developer Network docs
http://developer.mozilla.org/Project:en/How_to_Help
Write about Mozilla-related topics on Wikipedia
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mozilla

Maybe there is something you can do to further the cause, who knows.

[VanguardLH]

Documentation should be written from inside out. That is, the
developers are the first to define (describe) the expected behavior of
the product because, after all, they wrote it so they should know the
most about. Writing from inside out means the writer will only document
the features that they know about and probably only about the features
they use, not about all of them. You can get feedback regarding
corrections or omissions in the documentation from customers (users) but
the bulk of the document should first start with those who created the
product. Imagine how unreliable would be if the ingredients lists (as
incomplete as they already are) on the food you buy was written by the
consumers. How many of those consumers would have to suffer or die from
anaphylactic shock before the packaging listed peanuts or other known
allergic substances in the product?

[Peter Holsberg]

VanguardLH has written on 3/4/2013 9:58 PM:

> Documentation should be written from inside out. That is, the
> developers are the first to define (describe) the expected behavior of
> the product because, after all, they wrote it so they should know the
> most about. Writing from inside out means the writer will only document
> the features that they know about and probably only about the features
> they use, not about all of them. You can get feedback regarding
> corrections or omissions in the documentation from customers (users) but
> the bulk of the document should first start with those who created the
> product. Imagine how unreliable would be if the ingredients lists (as
> incomplete as they already are) on the food you buy was written by the
> consumers. How many of those consumers would have to suffer or die from
> anaphylactic shock before the packaging listed peanuts or other known
> allergic substances in the product?

What a terrible analogy! Developers frequently describe things in the
way and with terminology that they understand, which often does not
create something useful for the user.

Back in the day, we would send someone from the Education and Training
Department to write user documentation and they would usually have to
"work with" developers in an on-going process to reach a useful manual.
Frequently, a developer would say, "You left out X" and then there would
be a dialogue to get "Using X" into a form where a user could actually
use X.

[»Q«]

On Mon, 4 Mar 2013 20:58:35 -0600
VanguardLH <V...@nguard.LH> wrote:

> Jay Garcia wrote:
>
> > Interested in Writing and Documentation?
> >
> > Write Firefox Knowledge Base articles
> > http://support.mozilla.com/en-US/kb/improve-knowledge-base
> > Write Thunderbird Knowledge Base articles
> > http://support.mozillamessaging.com/en-US/kb/improve-knowledge-base
> > Help with Mozilla Developer Network docs
> > http://developer.mozilla.org/Project:en/How_to_Help
> > Write about Mozilla-related topics on Wikipedia
> > https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mozilla
> >
> > Maybe there is something you can do to further the cause, who knows.
>
> Documentation should be written from inside out. That is, the
> developers are the first to define (describe) the expected behavior of
> the product because, after all, they wrote it so they should know the
> most about. Writing from inside out means the writer will only
> document the features that they know about and probably only about
> the features they use, not about all of them. You can get feedback
> regarding corrections or omissions in the documentation from
> customers (users) but the bulk of the document should first start
> with those who created the product.

One of the beauties of open development is that anyone can follow it
and document it, which leaves the people who are developing the
browser free to develop the browser. (Of course, they're also free to
write end-user documentation as well, and some of them do.)

[Rob]

VanguardLH <V...@nguard.LH> wrote:
> »Q« wrote:
>

>> VanguardLH wrote:
>>
>>> I switched back to using my choice (PDFxchange Viewer) that I had
>>> selected before. The point is that *I had to switch back*. Mozilla
>>> should not be discarding user-configured settings. I found their
>>> update changed this setting. How many other tweaks might they have
>>> altered?
>>
>> They introduced a new browser feature and enabled it by default; this
>> will happen occasionally. They won't arbitrarily change your tweaks
>> though, and new features are mentioned in the release notes so you can
>> spot them easily.
>

> They were so enthused with their underwhelming achievement to produce a
> weak PDF viewer that they had to step on whatever users had already
> deployed. Oh yay, oi vey <rolleyes>.
>
> When I noticed the oddball PDF behavior, I looked at the release notes:
>
> http://www.mozilla.org/en-US/mobile/19.0/releasenotes/
>
> Mozilla's concept of "release notes" is not to *document* deletions,
> additions, or changes in functionality (so it would apply against a
> Functional Specification). It's just a list (aka changelog). All you
> see mentioned as the full documentation regarding this new functionality
> is "Built-in PDF viewer". Oh wow, how informative. I had to Google
> search to find a non-Mozilla article describing the new feature.
>
> The release notes don't document a changed or new feature. They just
> list it. Then it's up to the user to figure out how to fix the
> misbehaving program. I had previously played around with the PDF app
> association so when I saw the wrong PDF viewer getting used then I
> remembered about this app setting in Firefox. Other users won't be so
> lucky. They'll get stuck with Mozilla's choice.
>
> Because Mozilla chose to step on preferences changed by the user (i.e.,
> on settings changed from their defaults), now I have to consider how to
> best and easily save all setup before an update so I can step on Mozilla
> after Mozilla steps on me. I hadn't before considered that I had to
> protect myself from Mozilla.

What is even worse is that they try to "push" you into updating the
program "for security reasons", and then deliver new functionality that
breaks existing procedures as a by-product.

I have used Mozilla products at work for well over a decade, and it has
frustrated me many times. I update to a new version because it seems
to be time to cover some security problems, I do testing at my own
workstation for a week, then roll out to the company and all hell breaks
loose because of all the arbitrary changed and foulups of existing working
functionality. Then I can sweat and cover up things with scripts,
prefs.js changes, locked prefs and postings on the intranet, or sometimes
even rolling back to earlier versions that worked.

When you use Internet Explorer, you get firm releases that stay what
they are and are backed up with security fixes for a decade. You can
install the monthly "cumulative internet explorer update" with hardly
any testing as it will cover only security fixes and no functionality
sneak-ins.

When you install your monthly Firefox/Seamonkey update you essentially
get, besides the security updates, a snapshot of what is hot in
development and what the developers think is ready for production
(but often isn't)

It is bad. Really bad. Just like the "fast release schedule" and
many other stupid policy decisions.
In fact, in about half a years time we will be switching to using
Outlook/Exchange and IE instead of Seamonkey, which we have used
ever since the Netscape 4.7 days.

[Chris Ilias]

On 2013-03-04 9:58 PM, VanguardLH wrote:
> Documentation should be written from inside out. That is, the
> developers are the first to define (describe) the expected behavior of
> the product because, after all, they wrote it so they should know the
> most about. Writing from inside out means the writer will only document
> the features that they know about and probably only about the features
> they use, not about all of them. You can get feedback regarding
> corrections or omissions in the documentation from customers (users) but
> the bulk of the document should first start with those who created the
> product. Imagine how unreliable would be if the ingredients lists (as
> incomplete as they already are) on the food you buy was written by the
> consumers. How many of those consumers would have to suffer or die from
> anaphylactic shock before the packaging listed peanuts or other known
> allergic substances in the product?

Hi VanguardLH,

Your posting address doesn't appear to be valid, so this warning is
being posted here.

In the past I've already sent you 2 messages about your habit of posting
off-topic messages, and explained how to move discussions somewhere else
(like mozilla.general). The latest one was in this very thread just 6
days ago. Since then, I haven't seen any change in your behaviour. This
indicates to me that you're either not willing to follow the posting
rules, or you're just unable to follow them, and informing you about the
your habit of posting off-topic messages is having no effect.

As per <http://www.mozilla.org/about/forums/cancellation.html>, this
message is to inform you that your future infringing posts will be
removed from the news server without warning or comment.

I've set replies to go to my email address, rather than the newsgroup.
If you'd like to reply to this message, please email me with a valid
return address, thanks.

--
Chris Ilias <http://ilias.ca>
Mailing list/Newsgroup moderator

[VanguardLH]

At the software houses where I worked, they had a Documentation
department. The developers still had to write their own documentation.
First Sales and Marketing (and influenced by customer RFEs - requests
for enhancement) wrote the Functional Specification of what the product
was supposed to do. Development would then write the Engineering
Specification on how to implement the features specified in the
Functional Specification. The doc folks needed something to start with.
They didn't jump in blind. Yep, then they worked further with Dev and
QA to get more info on how the product actually worked. Before the
product went out the door, QA was supposed to review the documentation
not only to ensure that Shipping included it but also that it matched on
the version of the product being shipped, that there were no copy errors
(blank pages, upside down pages, missing pages, smudging, etc) and check
changes and workarounds were properly described so our customers not
only understood them but could use them (or not use them if they didn't
want them).

The doc folks talked to all developers since each one only knew how
their code worked and too often had little visibility of the
functionality outside their assigned duties. QA, because we had to test
the functionality per the Engineering Spec and because our job was to
see what would break so we had to know well the product, would review
the documentation because we would find the doc folks were incomplete or
had misunderstood what the devs had told them.

Whether you want to talk about devs, QA, or doc folks working to produce
usable documentation to users, that is still all *internal* to that
organization that produced the software. Asking customers (users) to do
the documentation is working outside in. You use them for feedback,
RFEs, or corrections but you don't expect them to write the docs.

[»Q«]

On Tue, 5 Mar 2013 23:00:39 -0600
VanguardLH <V...@nguard.LH> wrote:

> Whether you want to talk about devs, QA, or doc folks working to
> produce usable documentation to users, that is still all *internal*
> to that organization that produced the software. Asking customers
> (users) to do the documentation is working outside in.

If it has any meaning at all in an open project such as Mozilla,
"internal" means anybody who's willing to help. Unlike with the
projects you described working on, no one is walled out.

[crossposted, followup set]