brendandahl

Please file a bug https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c...

PDF.js dev here. I'm a bit confused on which part of internal API you would like to use? The way I think of it, there are really three API's in pdf.js: 1) Main thread API (api.js) which we base the version off 2) The code that runs in the worker 3) The viewer components (web/*)

Quite awhile ago when we decided what parts of the API to version, we thought more people would want to use #1. Now that the project is mature we could probably expose some more base the version off of that.

As for the "so that it doesn't look like PDF.js", we don't limit the API because of this. That suggestion (which I don't totally agree with) came from what we saw people doing, where they'd copy the entire viewer, when it'd probably be better to just let the user's browser choose how to show the PDF.

And it all comes back to HTML as dropbox uses pdf.js to show that PDF.

Patch author here. bzbarsky's comment covered most of it. It hasn't turned out to be that difficult. On linux, it was mostly playing whack-a-mole of avoiding calls in to gtk/x11 and then creating headless implementations of the platform specific code.

One slight complication of headless has been wiring up the headless "widgets" (in Firefox, we refer to most of the platform specific code as widgets e.g. there's gtk widgets, cocoa widgets, windows widgets). Usually the widget type is defined statically at build time, but in the case of headless we wanted Firefox to either use the headless widgets or the platform specific widgets at runtime. Luckily, some of the work on multi-process Firefox work also added another type of widget and made it much easier to support multiple types of widgets.

Overall, the hardest part has been trying to replicate all the events that would normally be triggered by the platform gui code. I've also found that these events and order can vary per platform which makes it hard to do in a non-platform specific way. We're still working out some issues here.

On the Firefox side, we are considering supporting the protocol or a subset of it. It seems many people have had lots of trouble with WebDriver/Selenium in the past and are hesitant to use it. However, it is nice that WebDriver has a W3C standard which could provide a nice path forward for headless cross browser use. This would probably require browser vendors to make it a first class citizen and work out some the kinks of the spec though.

BTW, I'm in Mozilla San Francisco office, so I'd be happy to chat about the headless cross browser future if anyone from the headless Chrome team is around.

Patch author here: To add to the other comments, you could also use SlimerJS[1]. Though I don't know if I'd consider that lower level. We're open to supporting other ways of controlling FIrefox and have been gauging feedback on what to support.

[1]https://slimerjs.org/

For those interested, Firefox is also going to support a headless mode. The current nightly supports headless SlimerJS on Linux and more platforms will come soon.

https://bugzilla.mozilla.org/show_bug.cgi?id=1338004

As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time.

Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js.

Yury and I are the only paid staff that work very occasionally on PDF.js. We both have not been full time on the project for quite awhile. We do have a pretty active community and quite a few outside companies using PDF.js though.

Chrome should enable turbo fan with the "use asm"; set. Though the only confirmation of this is saying it's tested in beta. https://code.google.com/p/v8/issues/detail?id=2599#c77

There's also "The location of the current gate to the Ridge is on state-owned property, and because of the width of the road and lack of adequate turnaround space" from

https://webcache.googleusercontent.com/search?q=cache:g9QMap...

Tech lead of pdf.js here: All of the above exploits were issues with extension code in firefox, i.e. other extensions could have these issues too. If you were to use the web only version of pdf.js none of these exploits would apply.

For those that are interested in doing the PCT and want to learn more I highly recommend the trail journal of Carrot Quinn on her 2013[1] hike. She gives an entertaining and real view of the trail.

I hiked the trail in 2014 and found it to be one of the hardest and most rewarding things I've ever done.

1. http://carrotquinn.com/pct-2013/

We're working on that https://github.com/mozilla/pdf.js/pull/2719

If he thinks PSD is bad he should try PDF which is really about 30 inconsistent formats all packaged into one inconsistent format.