486395 - Unable to copy url from location bar in popup

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Boris Zbarsky [:bzbarsky]]

STEPS TO REPRODUCE:

1)  Load attached HTML file
2)  Click the link
3)  Select the url in the url bar with the mouse.
4)  Cmd-C to copy it.

EXPECTED RESULTS: URL copied

ACTUAL RESULTS: Clipboard not affected.

This makes life suck a lot on sites that pop up the "printable" version of articles in a window like that; if I want to send the url to someone else, I have to jump through hoops.

ADDITIONAL INFORMATION:
1)  This is worksforme on Linux, but I can reproduce quite reliably on Mac.
2)  I did some debugging, and it looks like browser.css sets
    "-moz-user-input: disable" on the urlbar in this case (due to the readonly
    attribute).  This means that all event handling on the input is suppressed,
    because of the code in nsHTMLInputElement::PreHandleEvent.  In particular,
    the keypress event is just not dispatched at all, hence not seen by the XBL
    key event handler, and we get nowhere close to triggering the code in
    urlbarBindings.xml.  I would expect this to be the case on all platforms,
    though, so not sure why this works on Linux.
3)  Using the menu's Edit > Copy to copy the text works fine.
4)  For some reason there is no context menu for the url bar in this case.  I
    can file that as a separate bug, if it's caused by something other than the
    user-input styles above.

This looks like a regression from bug 419772.

Comment 1

[Boris Zbarsky [:bzbarsky]]

My obvious suggested fix is to remove that user-input style, fwiw.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 3

[Marco Bonardo [:mak]]

WFM in windows too

Comment 4

[:Gavin Sharp [email: [e-mail]]]

I can't think of a good reason to have that style, so removing it sounds good to me. Odd that it behaves differently on Linux and Windows, though...

Comment 5

[Boris Zbarsky [:bzbarsky]]

For what it's worth, this is the most annoying thing for me about daily Firefox use at this point...  I hit it all the time on sites that pop up windows for their "printer friendly" article versions.

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #4)
> Odd that it behaves differently on Linux and Windows, though...

That's because only pinstripe sets -moz-user-input: disabled; for #urlbar[readonly="true"].

Comment 7

[Dão Gottwald [:dao]]

Attachment: patch

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 374427 [details] [diff] [review]
patch

Oh, I didn't look closely enough and just saw the three hits across the three themes.

Comment 9

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/18acce63333a

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre ID:20090426031353

Comment 11

[joshr-mozilla]

I was going to file a bug against this too, but found it would have been a dupe. Still seeing this behavior in firefox 3.0.10.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This will not be fixed for any Firefox 3.0.x release. There is a good chance to have it in the upcoming Firefox 3.5.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 374427 [details] [diff] [review]
patch

a191, but I'd really like to see a test or a bug assigned to yourself to follow up with a test.

Comment 14

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/03488659774a

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090515 Shiretoko/3.5b5pre ID:20090515030938