Closed Bug 1337413 Opened 7 years ago Closed 7 years ago

Cannot Print from Firefox 51.0.1 (32-bit) on Windows 7 (64-bit)

Categories

(Core :: Printing: Output, defect)

51 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox51 - wontfix
firefox52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: bigdoodr, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Visit any webpage and try to print.


Actual results:

The print menu appears, but no matter which printer is selected, an error appears. (See attachment)

Reference https://support.mozilla.org/en-US/questions/1155587 for others experiencing this issue.


Expected results:

The page should print.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Could you run the tool mozregression to narrow down a regression range, please.
http://mozilla.github.io/mozregression/ (you need python 2.7 on OSX)

Run the command "mozregression --good=50" then copy here the final pushlog.
It would help to find the regressing bug.
Component: Untriaged → Printing: Output
Flags: needinfo?(bigdoodr)
Product: Firefox → Core
(In reply to Loic from comment #1)
> Could you run the tool mozregression to narrow down a regression range,
> please.
> http://mozilla.github.io/mozregression/ (you need python 2.7 on OSX)
> 
> Run the command "mozregression --good=50" then copy here the final pushlog.
> It would help to find the regressing bug.

In case it matters, my install of Fx on my Mac is not having the issue. It seems to be unique to Windows.

Can the gui version be used on my Winy7 machine instead? I installed it, but am struggling to navigate its interface.
I saw a similar report on the French community board: https://forums.mozfr.org/viewtopic.php?f=5&t=132456

I would be nice if we could find a user able to run mozregression.
bigdoodr, could you contact the reporter of the issue on SUMO?
(In reply to Loic from comment #3)
> I saw a similar report on the French community board:
> https://forums.mozfr.org/viewtopic.php?f=5&t=132456
> 
> I would be nice if we could find a user able to run mozregression.
> bigdoodr, could you contact the reporter of the issue on SUMO?

I installed mozregression on my Windows machine. When I ran the command "mozregression --good=50" it prompted "Was this nightly build good, bad, or broken?" and opened a web browser and went to the Firefox Nightly download page.

Am I doing something wrong? It needs to analyze the version of Fx already installed (51.0.1 32-bit for Windows 64-bit), right? It shouldn't have to download a nightly build.
No, it's the expected behavior. Mozregression works by dichotomy, it downloads and launches automatically nightly builds for you.

For each build launched, you make the test to reproduce the issue (here, printing) and you enter in the console if the nightly is good or bad.

After a run, you'll get a pushlog from mozilla-inbound repository, like https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b11e4beb29e7b0941121b93b10fc155c53a4e
(In reply to Loic from comment #5)
> No, it's the expected behavior. Mozregression works by dichotomy, it
> downloads and launches automatically nightly builds for you.
> 
> For each build launched, you make the test to reproduce the issue (here,
> printing) and you enter in the console if the nightly is good or bad.
> 
> After a run, you'll get a pushlog from mozilla-inbound repository, like
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b
> 11e4beb29e7b0941121b93b10fc155c53a4e

Thank you for the clarification! Here's the pushlog:
"16:46.12 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ddc9b2
697068639ae1980c6753f79578301eedf6&tochange=a4b0052954d201710b37d39fb4e583254382
086b

16:46.88 INFO: Looks like the following bug has the changes which introduced the
 regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1279699"
(In reply to bigdoodr from comment #6)
> (In reply to Loic from comment #5)
> > No, it's the expected behavior. Mozregression works by dichotomy, it
> > downloads and launches automatically nightly builds for you.
> > 
> > For each build launched, you make the test to reproduce the issue (here,
> > printing) and you enter in the console if the nightly is good or bad.
> > 
> > After a run, you'll get a pushlog from mozilla-inbound repository, like
> > https://hg.mozilla.org/integration/mozilla-inbound/
> > pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b
> > 11e4beb29e7b0941121b93b10fc155c53a4e
> 
> Thank you for the clarification! Here's the pushlog:
> "16:46.12 INFO: Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=ddc9b2
> 697068639ae1980c6753f79578301eedf6&tochange=a4b0052954d201710b37d39fb4e583254
> 382
> 086b
> 
> 16:46.88 INFO: Looks like the following bug has the changes which introduced
> the
>  regression:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1279699"

Thanks for reporting this and helping to debug.

That particular patch was backed out, but it's possible that the patch that did eventually land for that bug is causing your issues.

It seems like something is going wrong with the creation of the temporary directory to which the sandboxed content process is allowed to write.

A few questions:
While Firefox is running, do you have a directory called "Temp-{<a guid>}" in the following directory?
C:\Users\<username>\AppData\LocalLow\Mozilla

Could you tell me what you have the following pref set to (in about:config)?
security.sandbox.content.level

Would you also test with security.sandbox.content.level set to 0.
You will need to restart Firefox after setting that pref, for it to take effect.
Blocks: 1279699
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Bob Owen (:bobowen) from comment #7)
> (In reply to bigdoodr from comment #6)
> > (In reply to Loic from comment #5)
> > > No, it's the expected behavior. Mozregression works by dichotomy, it
> > > downloads and launches automatically nightly builds for you.
> > > 
> > > For each build launched, you make the test to reproduce the issue (here,
> > > printing) and you enter in the console if the nightly is good or bad.
> > > 
> > > After a run, you'll get a pushlog from mozilla-inbound repository, like
> > > https://hg.mozilla.org/integration/mozilla-inbound/
> > > pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b
> > > 11e4beb29e7b0941121b93b10fc155c53a4e
> > 
> > Thank you for the clarification! Here's the pushlog:
> > "16:46.12 INFO: Pushlog:
> > https://hg.mozilla.org/integration/mozilla-inbound/
> > pushloghtml?fromchange=ddc9b2
> > 697068639ae1980c6753f79578301eedf6&tochange=a4b0052954d201710b37d39fb4e583254
> > 382
> > 086b
> > 
> > 16:46.88 INFO: Looks like the following bug has the changes which introduced
> > the
> >  regression:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1279699"
> 
> Thanks for reporting this and helping to debug.
> 
> That particular patch was backed out, but it's possible that the patch that
> did eventually land for that bug is causing your issues.
> 
> It seems like something is going wrong with the creation of the temporary
> directory to which the sandboxed content process is allowed to write.
> 
> A few questions:
> While Firefox is running, do you have a directory called "Temp-{<a guid>}"
> in the following directory?
> C:\Users\<username>\AppData\LocalLow\Mozilla
> 
> Could you tell me what you have the following pref set to (in about:config)?
> security.sandbox.content.level
> 
> Would you also test with security.sandbox.content.level set to 0.
> You will need to restart Firefox after setting that pref, for it to take
> effect.

Q1: Yes, there is a directory (technically multiple directories) of "Temp-{<a guid>}".

Q2: "security.sandbox.content.level" was set to "default" with a value of "1"

Q3: When changing that value to "0" and restarting, everything prints just fine.
[Tracking Requested - why for this release]:
(In reply to bigdoodr from comment #8)

> Q1: Yes, there is a directory (technically multiple directories) of
> "Temp-{<a guid>}".
> 
> Q2: "security.sandbox.content.level" was set to "default" with a value of "1"
> 
> Q3: When changing that value to "0" and restarting, everything prints just
> fine.

Thanks again, so the directory is getting created, but for some reason you don't have access to write to it from the sandboxed process.

It's possible that this is the same underlying problem as bug 1321724.
It would be good to retest this bug once that one has been uplifted to Beta.

I'll re-flag you for information once it has, if that's OK.
Flags: needinfo?(bigdoodr)
See Also: → 1321724
(In reply to Bob Owen (:bobowen) from comment #10)
> (In reply to bigdoodr from comment #8)
> 
> > Q1: Yes, there is a directory (technically multiple directories) of
> > "Temp-{<a guid>}".
> > 
> > Q2: "security.sandbox.content.level" was set to "default" with a value of "1"
> > 
> > Q3: When changing that value to "0" and restarting, everything prints just
> > fine.
> 
> Thanks again, so the directory is getting created, but for some reason you
> don't have access to write to it from the sandboxed process.
> 
> It's possible that this is the same underlying problem as bug 1321724.
> It would be good to retest this bug once that one has been uplifted to Beta.
> 
> I'll re-flag you for information once it has, if that's OK.

Certainly. Thanks!
Hi, the fix from bug 1321724 is now in the latest Beta version (52.0b6).
https://www.mozilla.org/en-US/firefox/channel/desktop/

Not sure if you've used separate profiles before, but if you run Firefox Beta as follows, you can create a separate profile for testing:

firefox.exe -no-remote -P

Thanks for testing this.
Flags: needinfo?(bigdoodr)
(In reply to Bob Owen (:bobowen) from comment #12)
> Hi, the fix from bug 1321724 is now in the latest Beta version (52.0b6).
> https://www.mozilla.org/en-US/firefox/channel/desktop/
> 
> Not sure if you've used separate profiles before, but if you run Firefox
> Beta as follows, you can create a separate profile for testing:
> 
> firefox.exe -no-remote -P
> 
> Thanks for testing this.

Fantastic! That seems to have fixed it.

Thank you!
(In reply to bigdoodr from comment #13)

> Fantastic! That seems to have fixed it.
> 
> Thank you!

Excellent, thanks for confirming.

I'll fill out the request for uplift to release in that bug, but this would only be considered if we had to have a dot release for some other reason.
Even then they may decide not to take it, so we'll probably have to wait until 52 (7th March) until this gets into release.
Status: NEW → RESOLVED
Closed: 7 years ago
Depends on: 1321724
Flags: needinfo?(bigdoodr)
Resolution: --- → FIXED
Blocks: 1335696
Blocks: 1340166
Blocks: 1336657
We don't have the plan for dot release and we will have 52 RC next week. We can let it ride the train on 52 and mark 51 won't fix.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: