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)

x86
Windows 7
defect
Not set
normal

Tracking

(blocking2.0 Macaw+, status2.0 .1-fixed, status1.9.2 wanted)

RESOLVED FIXED
Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed
status1.9.2 --- wanted

People

(Reporter: quidam, Assigned: jimm)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 3 obsolete files)

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
Flags: blocking-firefox3.6?
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
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
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"!
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
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+
(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.
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
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+ → -
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.
(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.
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.
This is reproducible in 3.6 as well, and unfortunately it doesn't happen in debug builds.
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.
re-nominating -- this is a really terrible experience any time you open a PDF on Windows in the browser
blocking2.0: - → ?
cc'ing Rudy who's been helping us with Reader X issues.
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: ? → -
I haven't seen this but I'll have someone test this internally.
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.
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.
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.
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.
(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.
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
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
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.
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.
Attached patch one off patch (obsolete) — Splinter Review
Attached patch one off patch (obsolete) — Splinter Review
minus some left over debug gunk.
Attachment #520291 - Attachment is obsolete: true
Attachment #520292 - Attachment is patch: true
(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.
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.
(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.
Attached patch fix (obsolete) — Splinter Review
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
Attached patch fixSplinter Review
I want the is visible check on the suspect window.
Attachment #521885 - Attachment is obsolete: true
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+
http://hg.mozilla.org/mozilla-central/rev/ef57f679db3f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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?
does this solve bug 627275 as well?
(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?
blocking2.0: - → Macaw
status2.0: --- → wanted
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+
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.
(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.
(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
(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
i am still seeing this on 9.0b1 with adobe 10.1.1.33
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ago13 years ago
Resolution: --- → FIXED
(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
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.