Address bar and other text edits stop working after loading a pdf into the browser using Adobe Reader X

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: Yet Ding, Assigned: jimm)

Tracking

({regression})

unspecified
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

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

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

fix
1.39 KB, patch
Ben Turner (not reading bugmail, use the needinfo flag!)
: review+
dveditz
: approval2.0+
Details | Diff | Splinter Review
(Reporter)

Description

8 years ago
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
(Reporter)

Updated

8 years ago
Flags: blocking-firefox3.6?
(Reporter)

Updated

8 years ago
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
(Reporter)

Comment 2

8 years ago
Adobe Acrobat

    Datei: nppdf32.dll
    Version: 9.1.0.163
    Adobe PDF Plug-In For Firefox and Netscape
(Reporter)

Comment 3

8 years ago
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

8 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

7 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
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

7 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

7 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
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

7 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

7 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

7 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

7 years ago
This is reproducible in 3.6 as well, and unfortunately it doesn't happen in debug builds.
(Assignee)

Comment 14

7 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

7 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

7 years ago
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: ? → -

Comment 18

7 years ago
I haven't seen this but I'll have someone test this internally.

Comment 19

7 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

7 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

7 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

7 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.

Updated

7 years ago
Duplicate of this bug: 637039

Updated

7 years ago
Duplicate of this bug: 636778

Comment 25

7 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)

Updated

7 years ago
Duplicate of this bug: 626491
(Assignee)

Comment 27

7 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

7 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)

Updated

7 years ago
Duplicate of this bug: 641024
(Assignee)

Comment 29

7 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.
Duplicate of this bug: 640623
(Assignee)

Comment 31

7 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

7 years ago
Created attachment 520291 [details] [diff] [review]
one off patch
(Assignee)

Comment 33

7 years ago
Created attachment 520292 [details] [diff] [review]
one off patch

minus some left over debug gunk.
Attachment #520291 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Attachment #520292 - Attachment is patch: true
(Assignee)

Comment 34

7 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

7 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

7 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.

Updated

7 years ago
Duplicate of this bug: 643824
(Assignee)

Comment 38

7 years ago
Created attachment 521885 [details] [diff] [review]
fix

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

7 years ago
Created attachment 521887 [details] [diff] [review]
fix

I want the is visible check on the suspect window.
Attachment #521885 - Attachment is obsolete: true
(Assignee)

Comment 40

7 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

7 years ago
http://hg.mozilla.org/mozilla-central/rev/ef57f679db3f
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 43

7 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

7 years ago
does this solve bug 627275 as well?
(Assignee)

Updated

7 years ago
Duplicate of this bug: 627275
(Assignee)

Comment 46

7 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?
Duplicate of this bug: 645919
blocking2.0: - → Macaw
status1.9.2: --- → wanted
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+

Comment 49

7 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

6 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

6 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

6 years ago
status2.0: wanted → .1-fixed

Comment 52

6 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

6 years ago
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
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED

Comment 55

6 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
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.