Browser debugging beyond the console


  • Discourse touched me in a no-no place

    So our web product produces a form for people to view: we have a template PDF with a form and some JS embedded in it. The URL contains obfuscated information, and when the PDF is loaded, it grabs the URL, deobfuscates the info, and plops it into the form. It's worked well for a dozen years, but some time this spring, IE 11 made a change such that either the JS doesn't or something else doesn't work, because the form shows up without the fields filled in. The problem is there's nothing in the browser JS console or otherwise in the dev tools to figure out what's going on. We told people "it's OK, use Chrome while we look for a fix." Today a client called in and said--you guessed it--Chrome 44 doesn't work any more. That's even worse: you just get a blank gray background without even the PDF itself showing. Again, nothing in the F12 tools, and this worked in 43.

    Anyone have any thoughts? This may mean I have to do something crazy like generate an image with some library, like people did back in the day with gd, and give up on the PDF approach.



  • @FrostCat said:

    So our web product produces a form for people to view: we have a template PDF with a form and some JS embedded in it. The URL contains obfuscated information, and when the PDF is loaded, it grabs the URL, deobfuscates the info, and plops it into the form. It's worked well for a dozen years, but some time this spring, IE 11 made a change such that either the JS doesn't or something else doesn't work, because the form shows up without the fields filled in. The problem is there's nothing in the browser JS console or otherwise in the dev tools to figure out what's going on. We told people "it's OK, use Chrome while we look for a fix." Today a client called in and said--you guessed it--Chrome 44 doesn't work any more. That's even worse: you just get a blank gray background without even the PDF itself showing. Again, nothing in the F12 tools, and this worked in 43.

    Anyone have any thoughts? This may mean I have to do something crazy like generate an image with some library, like people did back in the day with gd, and give up on the PDF approach.

    What's the point of the PDF? To print the form?

    Edit: I'm just wondering why you aren't doing this in a plain HTML page with a stylesheet specifically for printing - all browsers now have print to PDF and you can use modernizr to detect legacy browsers to show the old PDF if necessary.



  • IE is phasing out ActiveX, and Chrome/etc is phasing out NPAPI. Depending on what exactly your JS does, that's where I'd look.



  • @cdosrun1 said:

    IE is phasing out ActiveX, and Chrome/etc is phasing out NPAPI. Depending on what exactly your JS does, that's where I'd look.

    They're not killing NPAPI until Chrome 45: https://www.chromium.org/developers/npapi-deprecation


  • Discourse touched me in a no-no place

    @rad131304 said:

    : I'm just wondering why you aren't doing this in a plain HTML page

    Because someone else wrote this ten years ago and--so far--I haven't been allowed to redo it, just update it every time the underlying form changes, of course.



  • @FrostCat said:

    @rad131304 said:
    : I'm just wondering why you aren't doing this in a plain HTML page

    Because someone else wrote this ten years ago and--so far--I haven't been allowed to redo it, just update it every time the underlying form changes, of course.

    Did you try just adding a try catch and have it print any errors into the document (I'm assuming there are actually some errors that are just getting swallowed here)? It won't help for Chrome ATM, but it might give you a place to start in IE. I'm loathe to use println debugging, but I don't know of any other options unless your PDF development suite has some sort of JS debugger



  • You do realize that the Chrome stable branch is already at 44, right?


  • Discourse touched me in a no-no place

    @cdosrun1 said:

    IE is phasing out ActiveX, and Chrome/etc is phasing out NPAPI. Depending on what exactly your JS does, that's where I'd look.

    I don't see how that's relevant, tbh. If you disable the Chrome PDF viewer and enable Adobe, you get the "this plugin will soon stop working". But normally you would see the built-in Chrome viewer, which presumably doesn't use NPAPI--and in Chrome, it worked, from the time they put JS support in the plug-in up to Chrome 43.

    Also, in Edge, the PDF loads--it just doesn't fill in the forms. Also, I just now discovered that IE (as opposed to Edge) in Win10 works properly and fills the form. So I'm going to spend the next few minutes quietly banging my head against a wall.


  • Discourse touched me in a no-no place

    @rad131304 said:

    They're not killing NPAPI until Chrome 45

    If you disable the Chrome PDF viewer and enable the Adobe one--btw, Chrome 44 just dropped this week, so we've only got, what, 6 more weeks until the first people will start having that problem--you still get "this plugin needs permission to run" and have to click the yellow bar, click "Run all plugins on this page this time" and you still get a yellow bar that says "this plugin will soon stop working."


  • Discourse touched me in a no-no place

    @rad131304 said:

    Did you try just adding a try catch and have it print any errors into the document

    Not yet, but that's the next step. I don't have Acrobat on my current machine, which means I need to plug in my old one, boot it up, etc.

    Also, we are still on Acrobat 8, because small business and/or cheapskatiness. But I'm going to ask about getting a new version.

    ETA:

    I did open Reader directly and paste the URL into the Open dialog, where I do get an error. I'm not sure if it's relevant or not--the JS hasn't been touched in a couple of years, and it worked until recently--but I'll go digging into it.



  • Well, all I can think of is to dive into the changelog:

    Here you have changes from the last 43 to the last 44:

    wow... that's a big ass changelog


  • Discourse touched me in a no-no place

    @Eldelshell said:

    wow... that's a big ass changelog

    Yep. And there's a lot of duplicate commit messages.



  • @powerlord said:

    You do realize that the Chrome stable branch is already at 44, right?

    All I was saying is that the problem isn't likely to be the NPAPI sunset since the problem should have cropped up in Chrome 42 when they made the last changes to NPAPI support according to the roadmap.



  • @FrostCat said:

    Also, in Edge, the PDF loads--it just doesn't fill in the forms. Also, I just now discovered that IE (as opposed to Edge) in Win10 works properly and fills the form. So I'm going to spend the next few minutes quietly banging my head against a wall.

    The biggest change between IE and Edge is the death blow to ActiveX (For my stuff, at least), which is very similar to killing NPAPI. Which while not totally gone, is getting harder and harder to enable.

    So that's still where I'd look, having not seen your code.



  • I don't understand why the browser, and not the Adobe PDF plugin, would be responsible for running the JS in PDF files.

    However, I do get why it no longer works in Chrome-- Chrome switched from using Adobe's plugin to using their own PDF implementation some time ago, and I wager their own version isn't nearly as compatible.

    EDIT: I guess all the posts before mine covered this, but I like to hear myself type so nyah.

    Sorry I don't really have any suggestions, other than try to get it working in Adobe Acrobat proper and going from there.

    Honestly, you're probably looking at a decent-sized dev effort to port the form to HTML5, like rad34276437264 suggests. (Although he naively assumes you haven't done this due to some conspiracy theory instead of the most Occam Razor's reason which is simply it never came up before.)


  • Discourse touched me in a no-no place

    @cdosrun1 said:

    So that's still where I'd look, having not seen your code.

    Well, the PDF loads, it just doesn't run the JS (or something else is happening.) I can look into that but it seems unlikely and I wouldn't know where to look. My JS isn't exciting: parse the URL, unobfuscate the contents, stuff them into form fields.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I don't understand why the browser, and not the Adobe PDF plugin, would be responsible for running the JS in PDF files.

    I'm pretty sure it's not. You can actually open the PDF in Reader by pasting the URL into the Open dialog, except it doesn't accept the full URL, which I didn't realize right away, so the parser fails.

    @blakeyrat said:

    However, I do get why it no longer works in Chrome-- Chrome switched from using Adobe's plugin to using their own PDF implementation some time ago, and I wager their own version isn't nearly as compatible.

    Well, their plugin used to work _except for the JS support. They added that support some time back, after the end of 2013 or so. With 44, though, the PDF doesn't display at all, just a gray background similar to the "oh snap" plugin failed to load thing, only without any error indication.

    @blakeyrat said:

    Honestly, you're probably looking at a decent-sized dev effort to port the form to HTML5, like rad34276437264 suggests.

    That's what I'm thinking I might have to do, or maybe dynamically generate the entire PDF, but that's probably more effort.

    @blakeyrat said:

    (Although he naively assumes you haven't done this due to some conspiracy theory instead of the most Occam Razor's reason which is simply it never came up before.)

    Sorry, no conspiracy except a conspiracy by the bosses not to change stuff that wasn't broken.



  • @blakeyrat said:

    Honestly, you're probably looking at a decent-sized dev effort to port the form to HTML5, like rad34276437264 suggests. (Although he naively assumes you haven't done this due to some conspiracy theory instead of the most Occam Razor's reason which is simply it never came up before.)

    You know nothing about me; fuck off and die in a fire you raging douhcebag. I was trying to help, you're being a narcissistic fuckwit.



  • @FrostCat said:

    PDF with [...] some JS embedded in it


  • Discourse touched me in a no-no place

    I didn't design it and so far, as I said, I have not been able/allowed to change it.



  • It's possible that the Chrome PDF viewer decided to stop running JS in PDF files...

    Try putting in a script like this:

    try {
      alert("alert()");
    } catch (e) {}
    try {
      app.alert("app.alert()");
    } catch (e) {}
    
    

    note: http://www.planetpdf.com/planetpdf/pdfs/ppjslc_commonex_1.pdf fills out Adobe Acrobat / 8 for me in Chrome PDF viewer

    If that's working, you can start doing alert()-based debugging ;P

    Actually, based on the fact that my experiments say that the JS is running, you might want to investigate whether they removed access to the current URL the page is showing...


  • Discourse touched me in a no-no place

    @riking said:

    It's possible that the Chrome PDF viewer decided to stop running JS in PDF files

    Sure, but before they supported JS at all, I would just get the PDF with nothing filled out--in the case of the example PDF you mention, you'd see the form with the fields blank. Then it started working. Now, instead of reverting to the old behavior, the pdf doesn't even load (or render; I dunno: as I said you just get a gray background in the entire tab. What's it mean? Chrome's not going to tell you.)



  • Disclaimer: I know nothing about JS embedded in PDF.

    However, if your problem were my problem, the first thing I would do is figure out how to make the PDF reader's JS engine show me an alert box, then use that to work out whether the PDF-embedded JS can still see the URL it's supposed to be parsing. Because this isn't really browser debugging, is it? It won't be the browser's JS engine that's filling in those form fields, it will be the one in the PDF reader.



  • @FrostCat said:

    What's it mean? Chrome's not going to tell you.)

    This might be an artifact of the "click to play" functionality.
    Chrome might no be able to detect it's only an pdf based on the url if you are doing fancy shit.
    This is how the planet pdf looks for me:

    Notice that little puzzle piece in the address bar ? That might be all the notice you get, if the plugin does not have a place on the screen, or is off to the side etc. etc.


  • Discourse touched me in a no-no place

    @swayde said:

    This might be an artifact of the "click to play" functionality.

    No, I don't get the puzzle piece.


  • Discourse touched me in a no-no place

    @flabdablet said:

    However, if your problem were my problem, the first thing I would do is figure out how to make the PDF reader's JS engine show me an alert box, then use that to work out whether the PDF-embedded JS can still see the URL it's supposed to be parsing.

    Yeah, that's not too hard: app.alert() instead of the browser's alert(). I had to do something else so I didn't get to do the second half of that.

    Even if the JS fails, why doesn't the static content render? If I load the page in Reader, even though the URL gets cut off, the JS fails, and I don't see the form filled out, I still see the static content.



  • Maybe you're crashing the renderer? Or it's bailing out on one of your elements.

    I wouldn't rule it out: https://pdfium.googlesource.com/pdfium/+/5d711cb33cebaaf194b40683359c74e648ac5342^!/


  • Discourse touched me in a no-no place

    @riking said:

    Maybe you're crashing the renderer? Or it's bailing out on one of your elements.

    Could be, even though it's hasn't been changed in longer than Chrome's PDF viewer has supported JS at all.


Log in to reply