1182181 - Printer properties are TOO persistent with FF 39.0 and Windows

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[Ben Myers]

Attachment: lj5200Properties.jpg

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

I attempted to change the printer properties shown in the attached JPEG.  I want to use Tray 2 as my default, printing on plain paper stock.  After making the change, clicking OK and printing, the properties still remain "Automatic" and "Color".  This makes Firefox unusable for any printing that I need to do from a browser, because it causes printer errors that need manual intervention.  System runs Windows XP with SP3, but same result with two different Lenovo Thinkpads running Windows 7 Professional.  Honestly, this is a showstopper, the first one I have seen with Firefox in many years.


Actual results:

See attached JPG.


Expected results:

I have a screen capture showing what the settings should be, but Bugzilla only permits a single attachment.

Comment 1

[Loic]

Did it use to work with previous versions of Firefox? Like 38 or 35?

Comment 2

[Ben Myers]

Yes, it worked flawlessly with FF 38 and earlier.

Comment 3

[Loic]

To be sure, could you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

If that doesn't change anything, as you're able to reproduce the issue, could you install the tool mozregression (see http://mozilla.github.io/mozregression/ for details) and find a possible regression range.
As you said FF38 worked, just run " mozregression --good-release 38" and stop when you get a pushlog (no need to bisect).

Comment 4

[Ben Myers]

So you are saying to create a fresh profile.  Then what happens to the several years of bookmarks I have accumulated?

Does this request imply that the FF development/test team is unable to recreate the problem?  If this was only my system, I would consider creating a new profile.  But, as I said previously, the problem also occurs with two other systems.  What I will do is test FF 38 printing from my almost pristine (used infrequently) laptop and see what happens.  And report results.

Once I have installed mozregression, where is it installed?  And from which folder/catalog do I run it?

Thank you.

Comment 5

[Ben Myers]

Here is what I get when I run as suggested.  It makes no sense at all to me.

C:\Python27\Scripts>mozregression --good-release 38
C:\Python27\lib\site-packages\requests\packages\urllib3\util\ssl_.py:90: Insecur
ePlatformWarning: A true SSLContext object is not available. This prevents urlli
b3 from configuring SSL appropriately and may cause certain SSL connections to f
ail. For more information, see https://urllib3.readthedocs.org/en/latest/securit
y.html#insecureplatformwarning.
  InsecurePlatformWarning
 0:04.89 LOG: MainThread INFO No 'bad' date specified, using 2015-07-10
Unable to find a matching date for release 38
Valid releases:
  5: 2011-04-12
  6: 2011-05-24
  7: 2011-07-05
  8: 2011-08-16
  9: 2011-09-27
 10: 2011-11-08
 11: 2011-12-20
 12: 2012-01-31
 13: 2012-03-13
 14: 2012-04-24
 15: 2012-06-05
 16: 2012-07-16
 17: 2012-08-27
 18: 2012-10-08
 19: 2012-11-19
 20: 2013-01-07
 21: 2013-02-19
 22: 2013-04-01
 23: 2013-05-13
 24: 2013-06-24
 25: 2013-08-05
 26: 2013-09-16
 27: 2013-10-28
 28: 2013-12-09
 29: 2014-02-03
 30: 2014-03-17
 31: 2014-04-28
 32: 2014-06-09
 33: 2014-07-21
 34: 2014-09-02
 35: 2014-10-13
 36: 2014-11-28
 37: 2015-01-12

Comment 6

[Ben Myers]

Look, I am not currently a software developer, but I a pretty good problem solver.  And it took me a lot of time to figure out that I had to install Python 2.7 first.  And then I had to figure out how to run mozregression, finding it in the scripts folder (or catalog) underneath Python.

In short, the information provided to me to help troubleshoot the problem was dreadfully incomplete.  WHAT is a pushlog?  How do I find it after running mozregression (not the GUI)?  If I am going to provide useful information to the FF team, then I need to have better information from you.

Comment 7

[Ben Myers]

At least I can use a different printer driver for the same printer.

Comment 8

[Loic]

(In reply to Ben Myers from comment #4)
> So you are saying to create a fresh profile.  Then what happens to the
> several years of bookmarks I have accumulated?

It's just a fresh profile for testing purpose, I didn't ask you to use a fresh profile to replace your current one. You can create many new profiles to test something then you delete them. It's a common troubleshooting solution, like safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode).

About mozreg, just read the FAQ, all is explained:
http://mozilla.github.io/mozregression/install.html
Yes, you need to install Python.

After that, you run mozregression and when you get the pushlog (like http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5), you stop and you copy here the console ouptut (last good+first bad builds, pushlog).

Comment 9

[Ben Myers]

Look, I am pretty technical compared to most people who use FF.  But the explanations provided so far are incomplete as far as I am concerned.  If the FF team expects help in debugging its product, there has to be more understanding that users are not software developers!  I included the console log from mozregression in one of my previous messages.  Is this what is needed.

And you know, I have my own work to do.  I cannot afford to spend hours and hours debugging FF.  So the question I have is whether or not the FF team has been able to re-create this problem which has manifested itself on three different computers here???????

Comment 10

[Loic]

You know, on BMO too, we cannot spend hours to reproduce a bug that only the user is able to reproduce. Hundreds of bugs are filed everyday, that's why we ask the user to help and provide as much technical details as possible.

A regression range is useful to narrow down the bug which introduced your issue.

You can use mozregression with dates, like --good=2015-01-01 --bad=2015-07-01 it should be enough to find the range.

Comment 11

[Ben Myers]

Pity. Seems like the job of software developers and testers is to reproduce bugs.  Back in the day when I did software development, that is exactly what we did.

Well, at this point, FF has become very disappointing after many years of use, especially since there has been little attempt to answer my questions raised in previous comments.  Since the FF team cannot replicate this error, and it takes altogether too much of my time to figure out what to do here, why don't you close out this Bugzilla report?  Somebody else can encounter it too.  Then somebody else.  But I am through spending my time trying to figure out what to do with the inadequate and arcane debugging tools supplied.  Good luck.

Comment 12

[Loic]

Did you try to fix mozreg on your machine? It's a pretty simple tool to use by command line.

Comment 13

[Ben Myers]

YES!!!!!  I RAN it.  See my comment number 5 for the results.  It is simple to use by a software developer, and I apparently suffered through a successful installation of it plus Python.  But I would not ever call it simple for an average user of FF.

Comment 14

[Loic]

In general, if you report a bug on BMO, that's you are more than an average user and you'll probably able to run a tool like mozreg to provide some technical details. 
My mom is an average user of Firefox and she will never write a bug report, believe me. :)

Did you get the pushlog from the console output?

Comment 15

[Ben Myers]

How does one get a "pushlog", whatever that may be?  Comment #5 contains the command line (console) output from a run of mozregression.  Is that the pushlog?

Comment 16

[Loic]

Nope, mozreg should ask you if each build donwloaded is good/bad (after your test), then by dichotomy, you should obtain the date of the last good build and the date of the first bad build, and see a pushlog like http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5

Comment 17

[Ben Myers]

As comment #5 shows, mozreg (or did you intend mozregression???) produced an output.  At this point, without reasonable and detailed instructions, I give up.  Frankly, the information I have received this far to debug is wanting, inadequate and insufficient.  I could add some more adjectives, but I think you get my point.  I am wasting my time.

Comment 18

[Ben Myers]

Probably best to close this one out.  Very difficult for a non-developer to get you the right info.  Alternate printer driver does not show same over-persistence of printer properties.  It's an old XP system, anyway, so the driver is now obsolete.  However, my son's Windows 7 system had a similar problem which I was unable to troubleshoot before he left town.  Please make FF debugging tools easier for a layman to use.  I have many years of software development experience, unfortunately with much older assemblers and compilers, and I found the tools and instructions to use absolutely unforgiving when asked to use them for debugging.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Hi Ben, I'm sorry you've had such a bad experience up to this point. I've tried reproducing this on my end with a LaserJet M1212nf and haven't had any luck so far (as far back as early 2014, I haven't been able to get altered settings to persist after changing something and printing). My worry is that this is specific to certain printer drivers, which could make it exceedingly difficult for others to reproduce.

Would you be interested in giving mozregression another chance if offered to try to walk you through any difficulties you hit along the way?

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Based on the inability to reproduce, I'm going to close this out as incomplete. Ben, if you ever want to take a shot at tracking this down in the future, please feel free to add a note here and I'd be happy to help.