Closed
Bug 537325
Opened 14 years ago
Closed 13 years ago
Address bar and other text edits stop working after loading a pdf into the browser using Adobe Reader X
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(blocking2.0 Macaw+, status2.0 .1-fixed, status1.9.2 wanted)
RESOLVED
FIXED
People
(Reporter: quidam, Assigned: jimm)
References
()
Details
(Keywords: regression)
Attachments
(1 file, 3 obsolete files)
1.39 KB,
patch
|
bent.mozilla
:
review+
dveditz
:
approval2.0+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 (.NET CLR 3.5.30729) i opened a pdf (embedded in firefox), while it loaded i tried to change part of the url (it is important to start marking at the urls end) thus i was not able to change the url anymore Reproducible: Always Steps to Reproduce: 1. open a pdf (eg. http://www.help.gv.at/Content.Node/documents/meldez.pdf ) while the page is loading: 2. mark part of the url, it is important to start at the urls end 3. delete or replace that part Actual Results: the url does not change you can not change the url anymore, also when the pdf is loaded Expected Results: you should be able to change the url if you switch the tab and then switch back you will be able to change the url again
Summary: the url in the adress bar cannot be changed anymore when i try to change part of it when pdf is loading → the url in the adress bar cannot be changed anymore when i try to change part of it while pdf is loading
Comment 1•14 years ago
|
||
What are you using to view the PDF? Firefox doesn't have built in PDF reading, so I don't think this is an issue with the browser; might be with the PDF reader you're using. --> Core::Plugins Can't block until we get a confirmation. Adding qawanted.
Component: General → Plug-ins
Flags: blocking-firefox3.6?
Keywords: qawanted
Product: Firefox → Core
QA Contact: general → plugins
Adobe Acrobat Datei: nppdf32.dll Version: 9.1.0.163 Adobe PDF Plug-In For Firefox and Netscape
i also tried this on 3.5 and on trunk in 3.5 there is no problem trunk also shows problems because adobe acrobat afaik the most often used software to open pdf i think this we should have a closer look at this by the way i also noticed that adobe acrobat is much more slowly loaded in 3.6 and trunk than in 3.5
Comment 4•14 years ago
|
||
Bug confirmed in v3.6, platform Win 7 It is a problem with browser since we click on its address bar and it cannot be changed. For example, we visited www.site.com/doc.pdf, but we want to go just to www.site.com. You cannot erase "doc.pdf"!
Comment 5•14 years ago
|
||
confirmed on windows 7 Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
OS: Windows Vista → Windows 7
Summary: the url in the adress bar cannot be changed anymore when i try to change part of it while pdf is loading → the url in the adress bar cannot be changed anymore when i try to change part of it while pdf is open
Comment 6•14 years ago
|
||
Jim, can you look into this? I'm not sure this is a blocker per se, as this happens in 3.6, but this sounds like it could be an OOPP regression. bsmedberg, feel free to mark this differently if you disagree.
Assignee: nobody → jmathies
blocking2.0: ? → final+
Assignee | ||
Comment 7•14 years ago
|
||
(In reply to comment #6) > Jim, can you look into this? I'm not sure this is a blocker per se, as this > happens in 3.6, but this sounds like it could be an OOPP regression. bsmedberg, > feel free to mark this differently if you disagree. Hmm, 3.6 didn't have the pdf reader out of process. Might be some other regression. I'll take a look.
Assignee | ||
Comment 8•14 years ago
|
||
Is anyone still able to reproduce on trunk nightlies? This is working for me. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101117 Firefox/4.0b8pre
Comment 9•14 years ago
|
||
How did you try to change the URL bar? By clicking it with the mouse, or using the keyboard, or some other method? Not a regression from 3.6, so not blocking anyway.
blocking2.0: final+ → -
Comment 10•14 years ago
|
||
i click the url with the mouse, then keyboard keystrokes are not registered. i could not get a reproducible STR yet. sometimes it works sometimes not. it may involve switching tab back and forth while pdf is loading. and the problem occurs when the pdf has been completely loaded as opposed to during loading.
Assignee | ||
Comment 11•14 years ago
|
||
(In reply to comment #10) > i click the url with the mouse, then keyboard keystrokes are not registered. > i could not get a reproducible STR yet. sometimes it works sometimes not. > it may involve switching tab back and forth while pdf is loading. and the > problem occurs when the pdf has been completely loaded as opposed to during > loading. That I can reproduce. Mouse works fine, keyboard strokes get robbed by the pdf reader. The cursor in the address bar indicates focus.
Assignee | ||
Comment 12•13 years ago
|
||
Shows up in Adobe Acrobat 10 w/ipc enabled and disabled. This is pretty ugly if you just drop a pdf into the browser. The navigation bar becomes useless.
Assignee | ||
Comment 13•13 years ago
|
||
This is reproducible in 3.6 as well, and unfortunately it doesn't happen in debug builds.
Assignee | ||
Comment 14•13 years ago
|
||
Last of all this isn't reproducible with Reader 9.4 in Fx 3.6 and 4.0, so it looks like it's a Reader X specific issue.
Comment 15•13 years ago
|
||
re-nominating -- this is a really terrible experience any time you open a PDF on Windows in the browser
blocking2.0: - → ?
Assignee | ||
Comment 16•13 years ago
|
||
cc'ing Rudy who's been helping us with Reader X issues.
Comment 17•13 years ago
|
||
A terrible experience is the tab being totally unnavigable after loading a PDF. This is, at most, a bit of a nuisance for people who are heavy into modifying URLs in the location bar. It's also not a new regression, looks like it's an Adobe Reader X issue. Not blocking. (I also can't reproduce with the latest version of Reader X on Windows 7, fwiw!)
blocking2.0: ? → -
Comment 18•13 years ago
|
||
I haven't seen this but I'll have someone test this internally.
Comment 19•13 years ago
|
||
This is working fine for me: Firefox Win 32 3.6.12 Win 7 Enterprise x64 Reader 10.0.1 ...with some trying of tab-switching. I couldn't make it happen, I can always type/delete in the URL bar.
Assignee | ||
Comment 20•13 years ago
|
||
File: nppdf32.dll Version: 10.0.0.396 Adobe PDF Plug-In For Firefox and Netscape 10.0.0 Hmm, so my steps in 3.6 to reproduce are: Open 3.6 w/ one empty tab drop a pdf off the desktop into that tab click on the address bar - no cursor, text is highlighted, typing doesn't work click on the search edit - "Google" is highlight, typing doesn't work click the search drop down, select default search engine everything goes back to normal This happen on the first window I open. After tI close that tab I can't reproduce. I'll try updating reader.
Assignee | ||
Comment 21•13 years ago
|
||
10.0.1 still has the issue for me. In a 4.0 nightly, it's worse for some reason - closing the tab and restarting the steps reproduces each time.
Comment 22•13 years ago
|
||
Tried exactly those steps with Reader X and Firefox 3.6.13 on Win 7 enterprise, and it works fine for me. I tried it with Reader Protected Mode off and on, and it works. I'm using Remote Desktop to my Win 7 machine, I can try on the physical machine later today but it's hard to believe that would make a difference.
Comment 25•13 years ago
|
||
(In reply to comment #24) > *** Bug 636778 has been marked as a duplicate of this bug. *** Should this have really been marked as a duplicate, the linked bug refers to Firefox 4 Betas/Nightlies not 3.6 as this bug refers to.
Assignee | ||
Comment 27•13 years ago
|
||
I've confirmed the fix in bug 550322 caused this. Not sure yet how we work around this in the pdf case though. That fix was an important Flash full screen hang fix.
Blocks: 550322
Assignee | ||
Updated•13 years ago
|
Summary: the url in the adress bar cannot be changed anymore when i try to change part of it while pdf is open → Address bar and other text edits stop working after loading a pdf into the browser using Adobe Reader X
Assignee | ||
Comment 29•13 years ago
|
||
Hmm, interesting. The window taking focus is a text edit created by the ACRORD32 module. The edit is marked visible although I don't see it. We split the calling thread off using ReplyMessage and process the event. From there, focus in the browser gets hosed.
Assignee | ||
Comment 31•13 years ago
|
||
Rudi, question for you if you can answer it. Adobe reader is creating an odd widget, it's an Edit class, the window is visible, but the location of the window is off screen and the client area is zero. This bug when it shows up is due to strange interaction between the creation of this edit and our main window. Curious if you can shed any light on what that edit is for. I'll attach a patch that one offs this. I'm not very happy with it but after poking at this for a while I've not come up with much of anything slick that fixes this.
Assignee | ||
Comment 32•13 years ago
|
||
Assignee | ||
Comment 33•13 years ago
|
||
minus some left over debug gunk.
Attachment #520291 -
Attachment is obsolete: true
Assignee | ||
Updated•13 years ago
|
Attachment #520292 -
Attachment is patch: true
Assignee | ||
Comment 34•13 years ago
|
||
(In reply to comment #31) > Rudi, question for you if you can answer it. Adobe reader is creating an odd > widget, it's an Edit class, the window is visible, but the location of the > window is off screen and the client area is zero. This bug when it shows up is > due to strange interaction between the creation of this edit and our main > window. Curious if you can shed any light on what that edit is for. > > I'll attach a patch that one offs this. I'm not very happy with it but after > poking at this for a while I've not come up with much of anything slick that > fixes this. Also, the edit has no parent, it's floating out there on it's own for some reason. It's pretty easy to find in Spy since it's at the root of the window list and is marked visible.
Comment 35•13 years ago
|
||
This doesn't sound familiar to me at all, I'll forward this to our dev group to see if anyone knows the answer. I can't repro this issue so I don't know. Did you try turning Reader Protected Mode OFF (Reader -> Preferences -> General)? You have to exit Reader after that and make sure no AcroRd32.exe processes are running, before it takes effect.
Assignee | ||
Comment 36•13 years ago
|
||
(In reply to comment #35) > This doesn't sound familiar to me at all, I'll forward this to our dev group to > see if anyone knows the answer. I can't repro this issue so I don't know. > > Did you try turning Reader Protected Mode OFF (Reader -> Preferences -> > General)? You have to exit Reader after that and make sure no AcroRd32.exe > processes are running, before it takes effect. Turning that off seems to have fixed it. Interesting too - that Edit window I was seeing is gone from the Spy window list as well w/protected mode disabled.
Assignee | ||
Comment 38•13 years ago
|
||
This should be relatively safe since regular processes aren't going to be integrated in with our UI. Those types of event would be async anyway, according to msdn.
Attachment #520292 -
Attachment is obsolete: true
Assignee | ||
Comment 39•13 years ago
|
||
I want the is visible check on the suspect window.
Attachment #521885 -
Attachment is obsolete: true
Assignee | ||
Comment 40•13 years ago
|
||
Comment on attachment 521887 [details] [diff] [review] fix Ben, msg me on irc for details.
Attachment #521887 -
Flags: review?(bent.mozilla)
Comment on attachment 521887 [details] [diff] [review] fix r=me if we can change the early return to a simple break (with handled == PR_FALSE still).
Attachment #521887 -
Flags: review?(bent.mozilla) → review+
Assignee | ||
Comment 42•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/ef57f679db3f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 43•13 years ago
|
||
Comment on attachment 521887 [details] [diff] [review] fix I think we should consider getting this into 4.0. It's a pretty serious bug for those that experience it. (unusable browser after loading a pdf into a tab.)
Attachment #521887 -
Flags: approval2.0?
Comment 44•13 years ago
|
||
does this solve bug 627275 as well?
Assignee | ||
Comment 46•13 years ago
|
||
(In reply to comment #44) > does this solve bug 627275 as well? Yes it appears to. Would you mind testing tomorrow's nightly to confirm?
Updated•13 years ago
|
Comment 48•13 years ago
|
||
Comment on attachment 521887 [details] [diff] [review] fix Approved for the mozilla2.0 repository, a=dveditz for release-drivers Does this patch fix 3.6.x as well? Or is the problem less bad in that version?
Attachment #521887 -
Flags: approval2.0? → approval2.0+
Comment 49•13 years ago
|
||
WFM on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre Plugin: File: nppdf32.dll Version: 10.0.1.434 Adobe PDF Plug-In For Firefox and Netscape 10.0.1 Editing a link after opening a pdf is possible in the build above.
Assignee | ||
Comment 50•13 years ago
|
||
(In reply to comment #48) > Comment on attachment 521887 [details] [diff] [review] > fix > > Approved for the mozilla2.0 repository, a=dveditz for release-drivers > > Does this patch fix 3.6.x as well? Or is the problem less bad in that version? It's "less bad" basically. We could land it there too, it's a pretty safe patch.
Assignee | ||
Comment 51•13 years ago
|
||
(In reply to comment #48) > Comment on attachment 521887 [details] [diff] [review] > fix > > Approved for the mozilla2.0 repository, a=dveditz for release-drivers > > Does this patch fix 3.6.x as well? Or is the problem less bad in that version? http://hg.mozilla.org/releases/mozilla-2.0/rev/d46a8eac2278
Assignee | ||
Updated•13 years ago
|
Comment 52•13 years ago
|
||
(In reply to comment #46) > (In reply to comment #44) > > does this solve bug 627275 as well? > > Yes it appears to. Would you mind testing tomorrow's nightly to confirm? unfortunately it does not. i unduped and reopened Bug 627275
Comment 53•13 years ago
|
||
i am still seeing this on 9.0b1 with adobe 10.1.1.33
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 54•13 years ago
|
||
Could you please open a new bug? Because this one has already had a fix landed and various branch tracking flags set, we really don't want to reopen it.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Comment 55•13 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #54) > Could you please open a new bug? Because this one has already had a fix > landed and various branch tracking flags set, we really don't want to reopen > it. submitted Bug 703879
Comment 56•10 years ago
|
||
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•