User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141127110711 Steps to reproduce: Open some PDF files less than 5M in sdcard like attached file. Actual results: PDF files can not open or take long time to load Expected results: Normal opening of pdf

Hi DengWei, As we discussed by phone. There are different version of PDF with different size of picture. Moreover, language could also affect memory usage for loading a pdf. Thus we do not have a good approach to determine whether a user can accept a warning before opening a pdf. Please let me know if you still have other concern. Thanks

On the source code of pdfjs. As far as I know, I have two concerns. 1. Image is restricted to be drawn above 1024 * 1024 by following code (gaia/apps/pdfjs/content/web/viewer.js): --------------> window.navigator.mozSetMessageHandler('activity', function(activity) { var blob = activity.source.data.blob; => PDFJS.maxImageSize = 1024 * 1024; var fileURL = activity.source.data.url; <-------------- A. I wonder is there any reason why you make that restrict? Maybe low performance and memory are the primary concerns but I'd better confirm it with you. 2. The following appearance may be an issue. Prepare (gaia/apps/pdfjs/content/web/viewer.js): --------------> window.navigator.mozSetMessageHandler('activity', function(activity) { var blob = activity.source.data.blob; // remove the following code in order to draw those images above 1024 * 1024 // PDFJS.maxImageSize = 1024 * 1024; var fileURL = activity.source.data.url; <-------------- Build the ROM and flash it to your engineer phone. (1) Download the following pdf, click "下载(2.5M)" (Chinese): http://pan.baidu.com/s/1qWLYPcC (2) Enter Settings -> Download, open it. => The loading hint will keep still forever. We hope pdfjs can display the PDF document correctly. After my investigation, I found (gaia/apps/pdfjs/content/build/pdf.js) ---------------> PDFJS.disableWorker = (PDFJS.disableWorker === undefined ? false : PDFJS.disableWorker); <--------------- If apply the following modification, it will work EXPECTLY. ----------------> PDFJS.disableWorker = true; <---------------- Question: B. Why do you put that procedure to background? C. Why background workder behaves differently from front thread?

hi YiFan, Can you help to shed some light here? Thanks!

Dear Andrew, Could you please help to check partner questions per comment 2? Thanks!

Thank you for the help and effort Josh! Sorry for the late reply, I was occupied in another issue. For question A, yes it's for devices with limited memory space. You could always customize the value to suit your needs.

(In reply to yifan [:yifan][:yliao] from comment #5) > Thank you for the help and effort Josh! Sorry for the late reply, I was > occupied in another issue. > > For question A, yes it's for devices with limited memory space. You could > always customize the value to suit your needs. Thanks for your reply. But we pay more attention on Question B&C. Could you tell us your opinion?

(In reply to Josh Cheng [:josh] from comment #4) > Dear Andrew, > Could you please help to check partner questions per comment 2? > Thanks! I'm responding below, but note that I'm not really involved in pdf.js or the viewer other than when trying to prove that bugs are not the email app's fault ;) (In reply to Keith Tu from comment #2) > B. Why do you put that procedure to background? DOM Workers are used to allow the main thread to be more responsive by avoiding doing intensive processing on the main thread. > C. Why background workder behaves differently from front thread? I believe the intent is that they work the same. Since things need to be sent between the worker and the main page context, and since the workers have different globals/resources available, it's very possible for there to be bugs that result in them not operating the same. If there's something that fails to load with the worker enabled but succeeds with the worker disabled, I would expect there is a bug and that there may be error messages in the logcat output that would be useful in identifying the bug.

Thank you Andrew for providing the suggestion. Clear ni for now since I don't have any further information now. If your work around is not accepted please feel free to reopen this bug.

Hi Keith, Do you have any update for the suggestion we provided for comment 7?

(In reply to Andrew Sutherland [:asuth] from comment #7) > (In reply to Josh Cheng [:josh] from comment #4) > > Dear Andrew, > > Could you please help to check partner questions per comment 2? > > Thanks! > > I'm responding below, but note that I'm not really involved in pdf.js or the > viewer other than when trying to prove that bugs are not the email app's > fault ;) > > (In reply to Keith Tu from comment #2) > > B. Why do you put that procedure to background? > > DOM Workers are used to allow the main thread to be more responsive by > avoiding doing intensive processing on the main thread. > > > C. Why background workder behaves differently from front thread? > > I believe the intent is that they work the same. Since things need to be > sent between the worker and the main page context, and since the workers > have different globals/resources available, it's very possible for there to > be bugs that result in them not operating the same. > > If there's something that fails to load with the worker enabled but succeeds > with the worker disabled, I would expect there is a bug and that there may > be error messages in the logcat output that would be useful in identifying > the bug. Thanks for your information.

(In reply to Josh Cheng [:josh] from comment #9) > Hi Keith, > Do you have any update for the suggestion we provided for comment 7? Thanks for your help. We will update or create a new bug if any question.