Closed Bug 834075 Opened 8 years ago Closed 8 years ago
.js: The PDF url in the address bar becomes wrong in a certain situation .
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130109111322 Steps to reproduce: 1. Search "filetype:pdf any-keyword" in Google or in Yahoo. ex: keyword: "filetype:pdf book" https://www.google.co.jp/search?q=filetype%3Apdf+book&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-beta 2. Click the first search result link, and you will see the first PDF. Even if you see the message "The PDF might not be displayed correctly" and "Open With Different Viewer", Never click it. 3. Push the back button to go back to Google or Yahoo results. "Normally", the yellow bar will disappear when you push the back button. 4. Click the second serch result, and you will see the second PDF. After you see the second PDF, please go back to Google or Yahoo results. Please keep in mind that even if you see the message "The PDF might not be displayed correctly" and "Open With Different Viewer", Never click it. Please keep your eys on the address bar and check if the url is valid. 5. Please repeat the same things on the third search result or the followings in the exactky same way. Before you will see the five or six results, you will notice the following things. a. The url in the address bar is wrong. The url in the address bar wrongly becomes Google's url or the former PDF's url. It is not the url of the PDF which is shown currently in the browser window. Do you use the frame or iframe in PDF.js? Reloading window will correct the url in the address bar. b. But if you encouter the above phenomena, even if you fix the url by reloading the window, you will continue to see the yellow bar with the message "The PDF might not be displayed correctly" and "Open With Different Viewer", and at such time you can not close the yellow bar. In this case you have to close the tab and have to open a new tab to close the yewllow bar. Actual results: The url in the address bar becomes wrong when you keep opening PDFs and going back to the serach result in a row. Expected results: The url in the address bar should always show the url of the PDF which is shown in the browser window.
Is there any parameter of the PDF url to disable the message "The PDF might not be displayed correctly" and "Open With Different Viewer" by force? ex. http://..../hogehoge.pdf#page=3&unsupported_feature=0
Wfm with Firefox trunk on win7
Component: Untriaged → PDF Viewer
WFM too with FF21 on Win 7.
WFM means "Works for me", right? So you cannot reproduce the phenomenon I am describing about. It looks strange. In my environment, I can reproduce 100%. I tested with Firefox 19 beta1 with safe mode as well. And not only in Vista but also in XP or 7 I can reproduce it. Maybe my english is bad and you do not understand what I am describing about. I uploaded the page of how you can reproduce below. http://www.broadband-xp.com/test/firefox_url/firefox_url.html Whlie you are testing, have you seen the yellow bar with the message "The PDF might not be displayed correctly" and "Open With Different Viewer"? It seems you have to see the yellow bar twice or more in order to reproduce this phonomenon. And please do not hide yellow button during this test.
Do you need to google to reproduce the problem? If not, please paste URLs here.
I see. Since I am explaining from Google's search results, it may sound complicated. Sorry. As you point it out, it is not necessary since the urls pasted in this bugzilla are atomatically hyper-linked. Please simply acess to the urls below and open each PDF in the "same" tab. And please push the back button to go back to this bugzilla page, and repeat the same thing each by each. You will notice the url becomes strange in the forth PDF. Please keep in mind that you "do not" close the yellow tab with the message "The PDF might not be displayed correctly" and "Open With Different Viewer". http://www.anicom-pafe.com/book/saigai_techo.pdf http://g-book.com/downloads/startguide/mx_pro/AllPage-mX_Pro.pdf http://www.olc.co.jp/ir/pdf/factbook2012.pdf http://www.waseda.jp/navi/network/doc/proxy_safari.pdf http://www.cc.u-ryukyu.ac.jp/news/kouhou/No6/pdf/20.pdf
I couldn't still reproduce with the given testcase. That said, I have definitely seen the persisting infobar (but I don't recall the STR). Some other condition would be needed to reproduce the issue.
Priority: -- → P3
I just have seen this bug now, but I can't create a reliable STR yet.
I can reproduce in Nightly21.0a1 as well. http://hg.mozilla.org/mozilla-central/rev/4e7c92906a79 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130202 Firefox/21.0 ID:20130202030955 Reproducible: always Steps to Reproduce: 1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=834075#c6 2. Click 1st pdf link and then Navigation back 3. Click 2nd pdf link and then Navigation back 4. Click 3rd pdf link and then Navigation back --- Observe URL in Location bar --- Observe Notification Bar 5. Click 4th pdf link --- Observe URL in Location bar 6. Navigation back --- Observe URL in Location bar --- Observe Notification Bar Actual results: After step4: URL is wrong, Notification would not disappear. After step5: URL is wrong, The URL is 3rd pdf After step6: URL is wrong, Notification would not disappear. BROWSER WAS COMPLETELY BROKEN. BROWSER LIED. Expected Results; URL should indicate actual location. The notification bar should not display wrong information.
Oh, I was able to reproduce it on the latest Nightly, but not on Firefox 18. Alice, could you bisect the regression range?
I used the latest development add-on (currently 0.7.142) for all Firefox versions to eliminate the influence of the pdf.js version.
Regression window(m-c) with force pdfjs.disabled = false Good: http://hg.mozilla.org/mozilla-central/rev/a76c1f4c4112 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017110913 Bad: http://hg.mozilla.org/mozilla-central/rev/5142bbd4da12 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017191029 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a76c1f4c4112&tochange=5142bbd4da12 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/e78db739d589 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017121312 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/d896a7f47e02 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121017123513 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e78db739d589&tochange=d896a7f47e02 Suspected: af98d67916ad Ryan VanderMeulen — Bug 801280 - Update pdf.js to version 0.6.39. r=dtownsend
Error Console displayed the following error when pressing the back button in comment #9 step 4: Timestamp: 2013/02/03 22:20:20 Error: TypeError: can't access dead object Source File: chrome://browser/content/tabbrowser.xml Line: 388
I appears that the integrated find causes the DOM window leak.
Yury - how risky is the fix in https://github.com/mozilla/pdf.js/issues/2647?
(In reply to Alex Keybl [:akeybl] from comment #15) > Yury - how risky is the fix in https://github.com/mozilla/pdf.js/issues/2647? https://github.com/mozilla/pdf.js/pull/2668 ?
I cannot replicate the STR above in most of the cases. After testing the https://github.com/mozilla/pdf.js/pull/2668 patch, I could not replicate the problem yet, so I guess it's fixing the bug. Taking the this patch is really low risk.
Yes, https://github.com/mozilla/pdf.js/pull/2668 will fix this bug.
[Approval Request Comment] Bug caused by (feature/regressing bug #): bug 801280 User impact if declined: Really poor user experience. When a user opens broken PDFs and back several times, the tab will be unusable until close and reopen. Testing completed (on m-c, etc.): upstream pdfjs repo Risk to taking this patch (and alternatives if risky): very low String or UUID changes made by this patch: none
I am the original reporter. I confirmed this bug has been fixed with pdf.js 0.7.190 (Firefox 19 beta4). Thank you.
Comment on attachment 709987 [details] [diff] [review] Handle the error in case the sender is already unloaded Approving for Aurora/Beta, given this is a new feature and we should avoid breakage of this nature as much as possible.
Might this be related to #836463?
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130206083616 There is an automated test in the patch that verifies this isssue, PdfStreamConverter.js, and it passes on beta and aurora channels. Beta: https://tbpl.mozilla.org/php/getParsedLog.php?id=19470983&full=1&branch=mozilla-beta Aurora: https://tbpl.mozilla.org/php/getParsedLog.php?id=19470903&full=1&branch=mozilla-aurora I've tried to reproduce this issue manually using the steps from comment 9, but without success. It works for me on Firefox 19 beta 5.
Assignee: ydelendik → VYV03354
Whiteboard: [pdfjs-c-integration] → [pdfjs-c-integration][pdfjs-f-fixed-upstream] https://github.com/mozilla/pdf.js/pull/2668
The upstream fix has been merged into m-c.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Adding verifyme to flag for verification against Firefox 20 and 21.
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:20.0) Gecko/20100101 Firefox/20.0 Verified as fixed on Firefox 20 beta 1 (Build ID: 20130220104816).
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:21.0) Gecko/20100101 Firefox/21.0 Verified as fixed on Firefox 21 beta 2 (Build ID: 20130408165307) by using the steps from comment 9.
You need to log in before you can comment on or make changes to this bug.