Closed Bug 803713 Opened 12 years ago Closed 12 years ago

regression in old versions of Acrobat Plug-in in 18+

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Version:
19 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

(firefox17- unaffected, firefox18+ verified, firefox19+ verified, firefox20 verified, firefox-esr17 unaffected, b2g18 fixed)

Status:
VERIFIED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox17 - unaffected
firefox18 + verified
firefox19 + verified
firefox20 --- verified
firefox-esr17 --- unaffected
b2g18 --- fixed

People

(Reporter: mozilla, Assigned: emk)

References

Details

(Keywords: regression)

Attachments

(1 file)

patch and test
(deleted), patch
Biesinger
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review 
Using 20121019 nightly on a machine with Acrobat 8 Pro. The machine is part of a domain and Acrobat is not going to be updated any time soon. Whenever a PDF is encountered the CTP page appears, but clicking does nothing. The only workaround is to download the PDF to the local hard drive and load it in Acrobat 8.
Summary: CTP Doesn't for Acrobat → Plug-in Blocking Breaks Acrobat
I may have summarized this incorrectly as I'm not sure of the difference (if there is a functional difference at all) between plug-in blocking and CTP. When the Acrobat plugin is blocked there is a message to click to allow the document to display, that is what is broken here. The document never displays after clicking.
Sounds like it might be related/similar to bug 736998, but I'm having trouble reproducing this. Do you have a link you can share?
Also, you could try pdf.js: https://addons.mozilla.org/en-US/firefox/addon/pdfjs/ (although it looks like this is now in Nightly(?), which is why I'm having trouble reproducing this - maybe you have to explicitly disable the pdf plugin in about:addons).
Finally, if you're able to run Nightly on this computer, are you sure you can't install a more recent version of Adobe Reader?
I'll try disabling the Acrobat plugin, but installing Adobe Reader along with Acrobat Professional is not an option. It makes all kinds of issues with PDF document workflow on the machine.
Jerry, can you provide detailed STR? e.g. "search for 1040 in google and then click the link for the IRS 1040 form in PDF format".
Flags: needinfo?(mozilla)
STEPS TO REPRODUCE:

1. Click a link to any PDF anywhere.
2. See the "This plugin is vulnerable and should be updated" page.
3. Click "Click here to activate the Adobe Acrobat plugin".

RESULT
PDF doesn't load. Tab remains frozen until Acrobat process is force-closed or the tab is closed.

EXPECTED
PDF document loads.
Flags: needinfo?(mozilla)
I tried with http://www.irs.gov/pub/irs-pdf/f1040.pdf but I still can't reproduce on Windows 7 or OS X. Maybe this is an XP problem? The other thing is I don't have Acrobat Professional, just Reader, so maybe this is a problem with that specific plugin.
I do not see this issue at home using Acrobat X on Windows 7. It's a good data point. I hate to use XP and Acrobat 8, but the company isn't about to spring for 100,000 Windows 7 and Acrobat X licenses while they're laying people off.
Can we get some QA specifically on WinXP with an old version of Acrobat Reader?
Keywords: qawanted
Priority: -- → P1
This is the kind of situation which we specifically want the plugin to be able continue working, so marking for tracking 17. If this is a common problem we may need to remove the Acrobat blocklist entries until we can get this working.
tracking-firefox17: --- → ?
Tracking, will look for QA feedback about the question in comment 8 to determine what the next steps are.
tracking-firefox17: ? → +
tracking-firefox18: --- → +
Keywords: verifyme
I see 2 issues here, without having anything to do with the CTP blocklist:
1. Adobe Reader 8.1.2 (http://www.oldapps.com/adobe_reader.php?old_adobe=17?download) works on FF 17 but NOT on FF 18 and 19 - blank screen displayed. This is not 100% reproducible, after several tries I managed to see the pdf opened correctly.
2. On FF 19, in Tools/Options/Applications the pdfs are set to "Preview in Nightly", even if Adobe Reader is intalled (no matter what version). Opening a pdf in this situation will also show a blank screen.

Of course CTP doesn't work, if Adobe Reader itself doesn't do it.
> 2. On FF 19, in Tools/Options/Applications the pdfs are set to "Preview in
> Nightly", even if Adobe Reader is intalled (no matter what version). Opening
> a pdf in this situation will also show a blank screen.

Are you saying the builtin PDF viewer doesn't work at all? Or it doesn't work if we have CTP set up for Acrobat? That sounds like a different (perhaps more serious, although I'm not sure the status of pdf.js on the various trains) bug.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> > 2. On FF 19, in Tools/Options/Applications the pdfs are set to "Preview in
> > Nightly", even if Adobe Reader is intalled (no matter what version). Opening
> > a pdf in this situation will also show a blank screen.
> 
> Are you saying the builtin PDF viewer doesn't work at all? Or it doesn't
> work if we have CTP set up for Acrobat? That sounds like a different
> (perhaps more serious, although I'm not sure the status of pdf.js on the
> various trains) bug.

Doesn't work at all on http://samplepdf.com/sample.pdf.
Only now I see that it works on other sites like http://alojamientos.us.es/afcomput/docs/practicas/P1/Manual.pdf
(In reply to Paul Silaghi [QA] from comment #13)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> > > 2. On FF 19, in Tools/Options/Applications the pdfs are set to "Preview in
> > > Nightly", even if Adobe Reader is intalled (no matter what version). Opening
> > > a pdf in this situation will also show a blank screen.
> > 
> > Are you saying the builtin PDF viewer doesn't work at all? Or it doesn't
> > work if we have CTP set up for Acrobat? That sounds like a different
> > (perhaps more serious, although I'm not sure the status of pdf.js on the
> > various trains) bug.
> 
> Doesn't work at all on http://samplepdf.com/sample.pdf.
> Only now I see that it works on other sites like
> http://alojamientos.us.es/afcomput/docs/practicas/P1/Manual.pdf

This doesn't sound like the same issue that Jerry is running into, which happens for all PDFs. Can you file a separate bug and find a regression range?

Benjamin - is there anything we can do to disable CTP completely and see whether this Jerry's problem is definitely a CTP issue?
Keywords: steps-wanted
(In reply to Alex Keybl [:akeybl] from comment #14)
> This doesn't sound like the same issue that Jerry is running into, which
> happens for all PDFs. Can you file a separate bug and find a regression
> range?

You'll also want to see if pdfjs.disabled=true affects the outcome of this testing.
Disabling pdfjs does not seem to have any effect.
Seems to work OK in FF 17.
(In reply to Alex Keybl [:akeybl] from comment #15)
> (In reply to Alex Keybl [:akeybl] from comment #14)
> > This doesn't sound like the same issue that Jerry is running into, which
> > happens for all PDFs. Can you file a separate bug and find a regression
> > range?
> 
> You'll also want to see if pdfjs.disabled=true affects the outcome of this
> testing.

Bug 805463 filed.
I haven't been able to reproduce the original problem on Fx18 with the IRS forms examples using Adobe Reader 8, however I was able to reproduce the problem with http://samplepdf.com/sample.pdf example:

Good 9/19: http://hg.mozilla.org/mozilla-central/rev/80499f04e875
Bad 9/20: http://hg.mozilla.org/mozilla-central/rev/1e56d3016820
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80499f04e875&tochange=1e56d3016820

Which could point to: https://bugzilla.mozilla.org/show_bug.cgi?id=777946

I'm not sure Paul's bug in comment #19 was duped to the right bug.

about:addons doesn't say that the plugin has been blocked.

I apologize if this is noise. However I was not able to find the Pro version of Adobe, and with the one I had I was not able to reproduce on XP.
With Adobe Reader 8.1.2 (http://www.oldapps.com/adobe_reader.php?old_adobe=17?download) I see this:
http://img600.imageshack.us/img600/5791/ff18pdfissue2.png
But pressing OK loads the pdf successfully. This is not always reproducible.

With Adobe Reader 9.0 (http://www.oldapps.com/adobe_reader.php?old_adobe=18?download) I see this:
http://img845.imageshack.us/img845/1694/ff18pdfissue3.png
Pressing OK shows a blank screen. Reloading the page several times finally loads the pdf. Unfortunately I see the same behavior on FF 17.

I don't think these issues are related to CTP, I remember I took this screenshot when Adobe Reader wasn't blocked: http://img266.imageshack.us/img266/1294/ff18pdfissue.png

At this moment the Reader cannot be tested without the CTP because the block is instantly. Removing the Reader block on staging for testing would help. Don't know what else to do.
(In reply to Paul Silaghi [QA] from comment #21)
> At this moment the Reader cannot be tested without the CTP because the block
> is instantly. Removing the Reader block on staging for testing would help.
> Don't know what else to do.

I was going to say you could try testing with extensions.blocklist.enabled set to false, but there's a bit of a bug with that (bug 811375). In the meantime, you should be able to edit blocklist.xml in your profile directory to remove the entry that blocks Reader, and then restart firefox.
(In reply to David Keeler from comment #22)
> In the
> meantime, you should be able to edit blocklist.xml in your profile directory
> to remove the entry that blocks Reader, and then restart firefox.

Easier said than done. There is no single entry in my blocklist.xml that is obviously related to Acrobat. I did remove two elements that referenced the nspdf32.dll Acrobat plugin, but I still get the "click here to activate the Adobe Acrobat plugin" screen. It did eliminate the message about it being vulnerable.
Better solution for now:
1. set extensions.blocklist.enabled to false
2. close firefox
3. remove pluginreg.dat in your profile directory
4. restart firefox
Assignee: nobody → dkeeler
(In reply to David Keeler from comment #24)
> Better solution for now:
> 1. set extensions.blocklist.enabled to false
> 2. close firefox
> 3. remove pluginreg.dat in your profile directory
> 4. restart firefox

I'm seeing the same issue as described in comment 21 with ctp blocklist disabled on Nightly 20.0a1 (2012-11-20), Adobe Reader 9.0.
So it's not a CTP issue, but an Adobe one.
QA Contact: paul.silaghi
We have several different scenarios of reproduction in this bug. Does this satisfy qawanted? Is there something more needed from QA at this point?
I at least need a summary of the current state. AIUI the comments here, this bug no longer has anything to do with blocklisting, and it's just a regression in Acrobat? Is this regression specific to Acrobat 9? If so, I'd probably just WONTFIX the bug.
Paul, can you confirm if this only happens with Adobe Reader 9? Does it happen with any newer versions? Please try Adobe Reader 10 and 11.
It's a regression in Firefox between 17 and 18 where PDF documents will not display at all. Pressing reload repeatedly *sometimes* will get the document to display, but not always. The only workaround is to manually download the document or use Chrome or IE to load the PDF URL.

In my case it's a corporate environment with Acrobat Pro 8 with no option to change. We don't even have enough rights to install reader (which would wreak havoc on the PDF workflow anyway). I would hope testing isn't limited to the free reader since corporate environments are likely to have the Pro version and can't afford to upgrade every single time Adobe needs more money.
1. Install Firefox
2. Start with a new profile
3. Install Adobe Reader
4. Navigate to http://samplepdf.com/sample.pdf

Firefox 17 + Adobe Reader 9.4.0
> PDF CTP Blocked, clicking the overlay opens the PDF in the current Firefox tab

Firefox 17 + Adobe Reader 10.1.4
> PDF is not blocked, PDF immediately loads in the current Firefox tab

Firefox 17 + Adobe Reader 9.0
> PDF CTP blocked, clicking the overlay opens the PDF in the current Firefox tab

Firefox 17 + Adobe Reader 8.1.2
> PDF CTP blocked, clicking the overlay opens the PDF in the current Firefox tab

I'm not able to reproduce this issue. Paul or Juan, can you help determine if this is a regression in Adobe Reader that's now fixed?

Jerry, Adobe Reader 8 is 5 years old at this point. Unfortunately there is nothing we can do if your corporation insists on using old, insecure software. If we find something to fix in Firefox we will, but if it's found to be an Adobe Reader regression this will be WONTFIX.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #30)
> Jerry, Adobe Reader 8 is 5 years old at this point. Unfortunately there is
> nothing we can do if your corporation insists on using old, insecure
> software. If we find something to fix in Firefox we will, but if it's found
> to be an Adobe Reader regression this will be WONTFIX.

It's not Adobe Reader, it's Acrobat Professional. They are different products. Also, software that is 5 years old cannot have regressed in the last few months, by definition.
If this is only happening in Acrobat Professional there will be absolutely no way for us to regress this. We can only get the latest version. Anyone who can help out here would be appreciated. 

Jerry, since you seem to be able to point this to something breaking between Firefox 17 and 18, please assist us by testing the Firefox 18 Nightly builds to find the day where this started.
The only issues I see (comment 25) are in Reader 8 and 9. Reader 10, 11 work fine. I assume it's the same with Acrobat Pro 8, 9.
Anthony, if you really want to reproduce, simply restart FF and load again http://samplepdf.com/sample.pdf. Remember, they are intermittent.
And as I said before, this has nothing to do with click to play, I've tested with ctp disabled.

Jerry, I think you can install separately Adobe Reader 11 in addition to Acrobat 8 Pro without messing up the things on your machine. But if you say you don't have rights to do that, that's another problem.
Another solution for you would be to use Firefox's built-in pdf viewer. It's enabled in nightly. Just make sure in Tools/Options/Applications the pdfs are set to "Preview in Nightly".
(In reply to Paul Silaghi [QA] from comment #33)
> Jerry, I think you can install separately Adobe Reader 11 in addition to
> Acrobat 8 Pro without messing up the things on your machine.

I'm not aware of any way to have both on the same machine and use Reader for browser viewing only. We used to have Reader X on the office machines but it would keep hijacking the file associations and interfere with PDF document workflow.
(In reply to Jerry Baker from comment #34)
> I'm not aware of any way to have both on the same machine and use Reader for
> browser viewing only.
What about using the Reader for anything needs reading and Acrobat for anything else (create etc)?
(In reply to Paul Silaghi [QA] from comment #35)
> What about using the Reader for anything needs reading and Acrobat for
> anything else (create etc)?

I'm not aware of any method to communicate my intentions to the operating system. Sometimes opening a PDF is because I want to read it, and sometimes because I want to edit it. You can right-click on choose the application to open with, but that doesn't control what launches by default when your OCR scanning app launches a PDF. Also, you can't have both open at the same time, so if a document is opened in Reader you have to close it before opening it in Professional. I've had both on the same system and it gets to be a real hindrance.
As it stands, I don't think we're going to fix this. Mozilla made important changes to plugin loading in FF17 to support click-to-play and reduce leaks, and it's almost impossible to figure out why Acrobat doesn't load. Adobe certainly isn't going to fix this either, so there's no point in tracking it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
I suppose Chrome and IE have figured out a better way to load plugins that allows Acrobat to continue working. It's really unfortunate to be in the position to choose between PDF functionality or security and stability improvements in later releases of FF. I suppose having FF 17 for all eternity at work won't be a lot different than having old versions of Acrobat. If the goal is to improve security, forcing users to choose between security and functionality is probably not going to yield the best results. Functionality will always win because a secure system that doesn't do anything you need it to do is less useful than a vulnerable machine that does what you need it to do.
Removing qa keywords from this bug given wontfix status. Benjamin, should we untrack for Firefox 18 and 19?
Keywords: qawanted, steps-wanted, verifyme
(In reply to Jerry Baker from comment #38)
> I suppose Chrome and IE have figured out a better way to load plugins that
> allows Acrobat to continue working. It's really unfortunate to be in the
> position to choose between PDF functionality or security and stability
> improvements in later releases of FF. I suppose having FF 17 for all
> eternity at work won't be a lot different than having old versions of
> Acrobat. If the goal is to improve security, forcing users to choose between
> security and functionality is probably not going to yield the best results.
> Functionality will always win because a secure system that doesn't do
> anything you need it to do is less useful than a vulnerable machine that
> does what you need it to do.

Unfortunately, this comes down to a bug in an outdated version of a paid plugin that we don't have easy access to. At that, it is likely a bug in the plugin itself, which would probably not be worth working around.

As mentioned in comment 32, if you wish to take on the effort of testing old Firefox 18 nightly builds to find the date where this bug first surfaced, it would provide an excellent lead for what the problem may be.
Nightly 20120919 works, 20120920 doesn't.
Thanks Jerry. With each of those builds, can you go to about:buildconfig and indicate the changesets? Something like http://hg.mozilla.org/mozilla-central/rev/3c3a8eed0578 for the 2012-09-19 and 2012-09-20 builds. Thanks
The one obvious patch in this range is bug 778442, which could indeed cause issues with plugin initialization.

I created a try run with this patch reverted:
  https://tbpl.mozilla.org/?tree=Try&rev=96ea94f19bb5

Once the builds complete there we can see if they still suffer from the bug to verify if this is the cause.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I can always reproduce this bug in my system. I will upload my information Thursday evening. Hopefully that will help a bit.
Okay, a build with this patch reverted is available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jschoenick@mozilla.com-96ea94f19bb5/try-win32/

Jerry or Kshitij, can you test if this build produces the issue?
Assignee: dkeeler → jschoenick
Keywords: regression
Summary: Plug-in Blocking Breaks Acrobat → regression in old versions of Acrobat Plug-in in 18+
Sadly the test build still exhibits the same issue.
Bug 777946 is the only other thing that looks related on a quick glance.
My intuition is suspicious of Bug 791566.
I created a new profile for the nightly build which posted here for testing and I tried it on a few sites and the problem seemed fixed for me. I will test my default profile soon and post the results back here.
Jerry, could you also check this with a new profile or safe mode?
I have to wait until I'm at the office. I would be very surprised if there were two regressions on the same day that affected PDF loading depending on the profile state. Keep in mind that 9/19 builds work with the existing profile, so if backing out Bug 778442 fixes the issue on Kshitij's machine and not mine, then there's a separate regression that happened on the same day which is affected by something in the profile as well.
OK. I finally got back to the office today. A new profile does not improve the situation. Once I set pdfjs.disabled to false, and set nightly to use Acrobat, I have the same issue.
Alright, I setup another try build to revert bug 777946:
  https://tbpl.mozilla.org/?tree=Try&rev=261df8e56bc9

When that's done building we can see if that's the culprit.

Thanks again for helping track this down
Still seeing the issue.
(In reply to Jerry Baker from comment #57)
> Still seeing the issue.

Ack. There are no other obvious changes in this set that should really affect plugins - bug 791566 is related to JS proxies, rather than networking proxies, and isn't likely related.

Changes to the bug 777946 code have happened since that time though, so we can try a build of the parent cset of those changes, rather than just reverting on trunk, which will also rule out all changes after it:

  https://tbpl.mozilla.org/?tree=Try&rev=150b6f6d3850
Bingo! That build works.
(In reply to Jerry Baker from comment #59)
> Bingo! That build works.

Okay, one more to see if we can nail down when it stopped working:
  https://tbpl.mozilla.org/?tree=Try&rev=efbeee947fea
Sorry for the delay. That build also works.
(In reply to Jerry Baker from comment #61)
> Sorry for the delay. That build also works.

Unfortunately that means that bug 777946 is definitely not the culprit, but if you're willing to keep testing builds we can try to narrow it down further:

  https://tbpl.mozilla.org/?tree=Try&rev=1ff9072f8c1e
    and
  https://tbpl.mozilla.org/?tree=Try&rev=fc590427b6ab

Those two builds should narrow it down to a ~15 commit range
I hate to report that both of those builds work fine.
(In reply to Jerry Baker from comment #63)
> I hate to report that both of those builds work fine.

This just means that the regression is between 53c9b95ac864 and 1e56d3016820, we'll get there eventually, if only by brute force

  https://tbpl.mozilla.org/?tree=Try&rev=62e62745cda4
  https://tbpl.mozilla.org/?tree=Try&rev=81747631e355
  https://tbpl.mozilla.org/?tree=Try&rev=97f8ce7d0834
None of those builds work.
(In reply to Jerry Baker from comment #65)
> None of those builds work.

This narrows it down to df2fbeb72ca1, 3403a77db505, 6308bf69d2e1, or 2d6537a47627 - so one more batch of builds should find the culprit:

  https://tbpl.mozilla.org/?tree=Try&rev=41efc8116bc6
  https://tbpl.mozilla.org/?tree=Try&rev=9371cee89c50
  https://tbpl.mozilla.org/?tree=Try&rev=a2c8b4449f6b
All three of those builds appear to work.
This means the first non-working revision is bug 790617 part 2:
  http://hg.mozilla.org/mozilla-central/rev/2d6537a47627

This would affect plugin-byte range requests I believe

Makoto or Christian, do you know why this would adversely affect acrobat? It is known to extensively use byte range requests.
Blocks: 790617
status-firefox18: --- → affected
status-firefox20: --- → affected
status-firefox-esr17: --- → unaffected
|range| will point a space character here.
https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=90d8a63e061c#989
Then |range| will not change the value until nsCRT::atoll is called.
https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=90d8a63e061c#1004
Unlike the most atoi implementation, our nsCRT::atoll doesn't allow leading space characters.
https://mxr.mozilla.org/mozilla-central/source/xpcom/ds/nsCRT.cpp?rev=b3a9ae0f6abf#172

I think we should increment |range| by one after null check. Otherwise "*" check will not also make sense.
https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=90d8a63e061c#994
Flags: needinfo?(mozilla)
Assignee: jschoenick → VYV03354
Priority: P1 → P2
I tried on about a dozen different PDF docs I found by Googling filetype:PDF. All work as expected.
Flags: needinfo?(mozilla)
Attached patch patch and test (deleted) — — Splinter Review 
Thanks for cooperating.
I added a test to catch a future regression.
Attachment #694140 - Flags: review?(cbiesinger)
This seems reasonable enough, but I'm concerned about other places that might have depended on the space-skipping behaviour of atoll. Does anybody want to volunteer to check them all?
Comment on attachment 694140 [details] [diff] [review]
patch and test

+"Content-range: bytes 3-7/8\r\n"+

I think your test should also check multiple spaces
Attachment #694140 - Flags: review?(cbiesinger) → review+
(In reply to Christian :Biesinger (don't email me, ping me on IRC) from comment #73)
> This seems reasonable enough, but I'm concerned about other places that
> might have depended on the space-skipping behaviour of atoll. Does anybody
> want to volunteer to check them all?

Fortunately, nsCRT::atoll is used in only a few places.
https://mxr.mozilla.org/mozilla-central/search?string=nsCRT::atoll

https://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp?rev=21195f52311c&mark=2779-2779#2779
https://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp?rev=21195f52311c&mark=2874-2874#2874
pluginreg.dat is a machine generated file.

https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp?rev=21195f52311c&mark=1607-1607,1627-1627#1606
mRequestHead.PeekHeader(nsHttp::Content_Length); would returan a value without whitespaces:
https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpTransaction.cpp?rev=21195f52311c&mark=239-239#239
https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpResponseHead.cpp?rev=21195f52311c&mark=43-43#43

https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=21195f52311c&mark=970-970#964
CompressWhitespace() would trim the whitespaces.

https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=21195f52311c&mark=1004-1004#1004
This patch.

https://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/nsMultiMixedConv.cpp?rev=21195f52311c&mark=1006-1006#1006
According to the BNF, SP is not allowed after "/". And Acrobat 8 didn't break.
https://tools.ietf.org/html/rfc2616#section-14.16
(BTW, we may not consider about multiple spaces per the BNF.)

https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSComponent.cpp?rev=21195f52311c&mark=1253-1253#1253
This pref value would not be set by users.

https://mxr.mozilla.org/mozilla-central/source/toolkit/components/startup/nsAppStartup.cpp?rev=21195f52311c&mark=784-784#782
I don't think we need to worry about someone may prepend spaces before the MOZ_APP_RESTART environment variable.

So I concluded that no other places would need a fix.
Pushed with added multiple spaces test.
https://hg.mozilla.org/integration/mozilla-inbound/rev/7a025808ca17
Status: REOPENED → ASSIGNED
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/7a025808ca17
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Comment on attachment 694140 [details] [diff] [review]
patch and test

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 790617
User impact if declined: Firefox will not parse multipart partial responses correctly. In the read world, older Acrobat plug-ins would be affected.
Testing completed (on m-c, etc.): on m-c, try, and local
Risk to taking this patch (and alternatives if risky): Very low
String or UUID changes made by this patch: None
Attachment #694140 - Flags: approval-mozilla-beta?
Attachment #694140 - Flags: approval-mozilla-aurora?
We're approving for Beta given:
* pulling back CTP blocklists would have no impact on this, since it's a plugin regression
* the risk here has been deemed low
* we expect there to be significantly more users on old versions of Acrobat in our release population.

Please land no later than 12/26.

Masatoshi - please provide guidance for QA around verifying https://bugzilla.mozilla.org/show_bug.cgi?id=803713#c75 and any other possible regressions (loading other plugins?
tracking-firefox18: - → +
tracking-firefox19: - → +
Keywords: qawanted, verifyme
QA Contact: paul.silaghi → anthony.s.hughes
Attachment #694140 - Flags: approval-mozilla-beta?
Attachment #694140 - Flags: approval-mozilla-beta+
Attachment #694140 - Flags: approval-mozilla-aurora?
Attachment #694140 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/e0377059a5cd
https://hg.mozilla.org/releases/mozilla-beta/rev/5c862611265b

(In reply to Alex Keybl [:akeybl] from comment #79)
> Masatoshi - please provide guidance for QA around verifying
> https://bugzilla.mozilla.org/show_bug.cgi?id=803713#c75

The comment #75 is unrelated to this particular bug. It just explains that why no other changes are needed. If they were needed, new bugs would have been filed.

> and any other possible regressions (loading other plugins?

Although this bug happens to appear on a plug-in, it is essentially a networking bug. So network activities involving partial response (such as download resume) might be affected. (But I believe it's very unlikely.)
I was not able to reproduce this issue on Windows XP using FF 18b5 and following steps from Comment 5 and with / without conditions from Comment 24.

PDF had opened as expected using Adobe Reader XI and Foxit Reader too but I'm still not sure if this happens because of theese or not. 

So please someone who had verified this issue too and couldn't reproduce set flag as verified for FF18.

Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 (20121219074241)
After reloading several times, I'm still seeing the issue in comment 21 on FF 18b6 with Adobe Reader 9. But that's not the issue Jerry complained about. Download resume works fine as usual. I would say this bug is verified fixed based on comment 71.
We have verification against Firefox 18 but this still needs verification against Firefox 19 and 20. Can someone please assist?
status-firefox18: fixed → verified
Keywords: qawanted
QA Contact: anthony.s.hughes
(In reply to Anthony Hughes, Mozilla QA (:ashughes) [Away Jan 20-28] from comment #84)
> We have verification against Firefox 18 but this still needs verification
> against Firefox 19 and 20. Can someone please assist?

Verified Fixed on FF 19b2 on Windows XP. It works as expected, as it did on Comment 82.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0(20130116072953)
Thanks Mario.
status-firefox19: fixed → verified
Keywords: verifyme
I confirm the fix is verified on FF 20b1. on Windows XP:

Mozilla/5.0 (Windows NT 5.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0(20130220104816)

Can anyone confirm this is verified on b2g18 too? I don't have any device to test with.
status-firefox20: fixed → verified
(In reply to MarioMi (:MarioMi) from comment #87)
> Can anyone confirm this is verified on b2g18 too? I don't have any device to
> test with.

I don't think this has a test-case on b2g18, as there are no plugins. The patch has a unit test though.
(In reply to Georg Fritzsche [:gfritzsche] from comment #88)
> I don't think this has a test-case on b2g18, as there are no plugins. The
> patch has a unit test though.

Based on Comment 88, I am setting this Bug as Verified Fixed overall. Thanks Georg!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: