Closed Bug 413681 Opened 16 years ago Closed 16 years ago

can't paste into google spreadsheets in ff 3b2

Categories

(Core :: Widget: Cocoa, defect, P2)

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: wrn, Assigned: jaas)

References

(Depends on 1 open bug, )

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

create a google spreadsheet and try to copy something from some web page and then past into the spreadsheet.  No workee.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Hardware: PC → Macintosh
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012309 Minefield/3.0b3pre

The keyboard shortcut works for me, but the context-menu option fails.
Product: Firefox → Core
QA Contact: general → general
still present in beta 3 (as of 2/4)
I can't get the shortcuts to work at all.
(In reply to comment #5)
> I can't get the shortcuts to work at all.
>
What's your OS?


(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre)
> Gecko/2008012309 Minefield/3.0b3pre
> 
> The keyboard shortcut works for me, but the context-menu option fails.
Did you mean context-menu provided by google doc.


On 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) 
Gecko/2008020904 Minefield/3.0b4pre
I am unable to see the firefox context menu even when
dom.event.contextmenu.enabled = false
Biju, I was talking about the Google context-menu.
(In reply to comment #8)
> Biju, I was talking about the Google context-menu.
that context-menu should not work in this case as we have disabled script access to system clipboard.

Google context-menu can only be used to copy a set off cells from one range to another in a workbook. It will work even between sheets in same workbook, but not between workbook.
Google docs is outright not working for me as of FF3.0b3.  I have occasional success, but for the most part it utterly fails.   If I open a new session and have a document open it works for a while.   I usually work on two or three at a time.  I have had to revert to 2.0.x for the time being.   (Which really sucks =()

I have no idea how to approach this or help.

As a side note:  It appears that cut'n'paste may be completely broken now.
I need to clarify.  

 - The spreadsheets /usually/ open, but I experience wierdness once things get wonky.
 -  After some period of time or other event I can no longer type in them thoughg the d-pad keys continue work fine.  I can navigate the individual cells.
 - I never use the actual Documents, only Spreadsheets, ergo I really don't know if it affects anything else.
 - Closing all open spreadsheets and reopening do not work.
 - A restart will return me to nominal functionality.
 - cut'n'paste, even w/in the same sheet, are now less predictable than ever. 
Is this a duplicate of bug 418689? Is this Mac-only? What are some exact steps to reproduce the problem? How exactly are you trying to "paste into the spreadsheet"?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Perhaps this is related to bug 413882.
Duping to 413882, feel free to re-open if you're still experiencing this problem with a recent nightly.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking1.9?
Resolution: --- → DUPLICATE
In reply to Gavin Sharp's comment of 2/21, to reproduce this, do what I said when I submitted the bug.  I am traveling and don't have time to check out all the threads talked about above.  This is <not> a report of right-clicking not working.  I believe I submitted a bug on that which may have been a dupe.  Anyway, this is about pasting from the clipboard into a google spreadsheet.  According to google you can't do this by right-clicking -- you have to ctrl-v into the cell/cells you want to paste into.  This is what is not working.

I tried it with a build I just downloaded and no joy.  (hmmm... little tiny tabs...)

The last comment said to reopen, so I am.  Thnx
Bill
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008022204 Minefield/3.0b4pre, here is what I see when cutting and pasting some text from a web page into a newly created google spreadsheet.

1. Cut and paste some text from a web page using Command-C
2. Paste the text into a cell using Command V.

This works for me on Mac, but only after I double click in the cell.  When I compare to the behavior on Win XP, I simply select the cell and then cut and paste.
There have been bunch of problems reported about command+c/command+v
not working in beta3 and recent trunk nightlies (in particular see bug
417108).

Your report, Bill, predates beta3 (in fact it appears to be on beta2).
But it's possible that the problem you're reporting may have changed
as of beta3
Well, in ff3b3 you <can> double-click in a cell, and then ctrl-v whatever is on the clipboard into <that> cell.

Here's what I want.  It works in ff2.xxx but not in ff3.xxx

1.  goto finance.yahoo.com
2.  about half way down on rt. is a table named "rates"
3.  select the 3X6 table starting with "30 year fixed"
4.  paste (ctrl-v) into any google spreadsheet.
5.  Observe that it works in ff2...

By "works", I mean you wind up with the 3X6 table in the spreadsheet in 3X6 columns/rows, not in one cell

Thanks
/b
> By "works", I mean you wind up with the 3X6 table in the spreadsheet in 3X6
> columns/rows, not in one cell


Bill,

 Thanks.  It's hard for people who don't _use_ these apps to understand the user-interface issues.   It's also difficult to remember how to communicate this clearly.  This is the problem.  Cut 'n' paste works for putting data into a single cell.  It doesn't work for multi-cell paste.  Multi-cell cut works.

I have also had problems since the change to FF3b3 - sometimes the text-input completely stops.  Arrow-key navigation within the workbook works fine.   Text input ceases altogether for cells.  Even if I double click.

(In reply to comment #18)

Thanks, Bill.  You've given us a specific and easily reproducible
problem report.  Let's make this bug be about the STR ("steps to
reproduce") in comment #18.

Other problems should be reported elsewhere, possibly in new bugs.

Be aware that Google spreadsheets was broken in interesting ways after
2008-01-17 (when the patch for bug 403232 was landed).  Some of these
are reported at bug 413882 (see especially bug 413882 comment #18).
The patch for bug 413882, which landed on 2008-02-13 fixed these
problems.  (It also broke some other things, but as far as I know
these don't effect Google spreadsheets.  A patch (for bug 404433),
which hasn't yet landed, fixes all outstanding focus issues.  For more
a testing build made with that patch see bug 404433 comment #42.)

Problems that the patch for bug 404433 build doesn't fix (like this
one) are probably not focus bugs.
I can trace this problem back a long way -- as far back as 2006-11-25.
Earlier than that Google spreadsheets are (for some reason) simply
undisplayable -- going back even before Cocoa widgets were landed (on
2006-09-28).
Flags: blocking1.9?
Even if this isn't a Cocoa widgets bug, I think it must be a Mac bug
of some kind.  But for convenience's sake I'm going to call it a Cocoa
widgets bug.
Assignee: nobody → joshmoz
Status: REOPENED → NEW
Component: General → Widget: Cocoa
QA Contact: general → cocoa
Version: unspecified → Trunk
Though Google spreadsheets is undisplayable before 2006-11-25, I've
now managed to confirm that this _is_ a Cocoa widgets bug.

Though you can't see anything in a Google spreadsheet when you load
it, you _can_ see that one cell is highlighted.  If you paste into
this cell, save your spreadsheet, quit the browser, and then look at
the (same) spreadsheet with a browser that _can_ display it, you can
see whether or not your paste succeeded.

Using this strategy, I've found that the STR from comment #18 doesn't
"work" with the Minefield 2006-09-28 nightly (just before Cocoa
widgets was landed) (using command+v to paste multiple rows and
columns works fine).  But this STR does "work" with the 2006-09-29
nightly (just after Cocoa widgets was landed) (using command+v to
paste multiple rows and columns does nothing at all).
Another interesting observation:

Though using command+v to paste multiple rows and columns works fine
in Firefox 2.0.0.12 (i.e. in 1.8-branch Firefox), it doesn't work in
Camino 1.5.5 (1.8-branch Camino).
Besides focus bugs, the other thing that occurred to me that this could be is bug 418226 (aka one of the symptoms of the backout of bug 358379, though the range may not be right), where nsChildView is blackholing events.

By the way, the official shortcuts (i.e., what Google is really watching/trapping) are all Ctrl-foo, not Cmd-foo; see http://docs.google.com/support/bin/answer.py?answer=66280&topic=8634
> Besides focus bugs, the other thing that occurred to me that this
> could be is bug 418226 (aka one of the symptoms of the backout of
> bug 358379, though the range may not be right), where nsChildView is
> blackholing events.

None of these bugs is likely to be related -- the regression ranges
are all wrong.  And if this is a focus bug, it's unlike (and unrelated
to) any that have been reported to date (again because of the
regression ranges).

> By the way, the official shortcuts (i.e., what Google is really
> watching/trapping) are all Ctrl-foo, not Cmd-foo; see
> http://docs.google.com/support/bin/answer.py?answer=66280&topic=8634

I noticed that, but don't know what to make of it.  Ctrl+v doesn't
work on any of the Mac browsers that I tried -- even those where
command+v works.  I suspect that this doc is simply wrong for the Mac.

> Though using command+v to paste multiple rows and columns works fine
> in Firefox 2.0.0.12 (i.e. in 1.8-branch Firefox), it doesn't work in
> Camino 1.5.5 (1.8-branch Camino).

It just occurred to me to test Safari.  But Safari doesn't have this
problem (command+v works, though ctrl+v doesn't).  So this isn't a
general problem with all Cocoa browsers.
By the way, does anyone know how to contact the Google spreadsheets
developers?  It's just possible that this is a Google bug.  And in any
case it'd be interesting to see what they might have to say.
(In reply to comment #26)
> > By the way, the official shortcuts (i.e., what Google is really
> > watching/trapping) are all Ctrl-foo, not Cmd-foo; see
> > http://docs.google.com/support/bin/answer.py?answer=66280&topic=8634
> 
> I noticed that, but don't know what to make of it.  Ctrl+v doesn't
> work on any of the Mac browsers that I tried -- even those where
> command+v works.  I suspect that this doc is simply wrong for the Mac.

This absolutely works fine in Safari and on the branch, but not on trunk.  Pasting from outside of Google Docs seems erratic everywhere, but on the trunk, even pasting inside Google Docs with the official shortcuts is broken.  

This bug seems to be about all sorts of things and it doesn't become clear what even after reading through many comments.  

The regression I noticed is that Google's official Ctrl-foo shortcuts, which work on branch and in Safari, don't work at all on the trunk.

That seems to be the most basic regression.  Then there are all of these other add-on regressions about Cmd should work but doesn't, and pasting columns of text from outside of Google Docs used to work, and so forth, but they all seem moot if the basic shortcut functionality (including copy/paste) don't work at all.
>> Ctrl+v doesn't work on any of the Mac browsers that I tried -- even
>> those where command+v works. ...
>
> This absolutely works fine in Safari and on the branch, but not on
> trunk.  Pasting from outside of Google Docs seems erratic
> everywhere, but on the trunk, even pasting inside Google Docs with
> the official shortcuts is broken.

You appear to be saying that ctrl+v works fine for you in Safari and
Firefox 2.0.0.12 (and also Camino 1.5.5?).

But are we talking about the same thing?

I'm talking about the STR from comment #18 (with the assumption that
(judging by his results) Bill clicked once (not twice) on a cell
before using command+v in step 4).

Are you really seeing ctrl+v work with that STR?

I just redid my tests of the STR from comment #18 in Firefox 2.0.0.12
and Safari, on both 10.5.2 and 10.4.11.  I got exactly the same
results -- command+v worked fine but ctrl+v didn't work (no results at
all).  I tested on an old MacBook Pro (one of the early models).

(I haven't yet tested the other Ctrl+foo commands, and you may be right
about them.)
I am the biggest of jerks.  In comment 18 I said I used "ctrl-v" to paste from the clipboard.  On a Mac.  Actually use "cmd-v".  I have caused much trouble.  Sorry.
/b
> Actually use "cmd-v".

I goofed too.  I'd simply assumed you said "cmd-v" (instead of
"ctrl-v"), and then forgot about it.

All of what I said still stands.  But it's possible that Smokey's
discovered some additional subtlety.

Smokey, please let us know if ctrl-v really works for you (in Safari
and Firefox 2.0.0.12) using the STR from comment #18.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Flags: blocking1.9+
Flags: tracking1.9+
Assignee: joshmoz → smichaud
Kev, here's another one where we could use help from Google.
Do we really need help from Google here?  Things work in win32 and linux, and they used to work in Fx2 -- seems like the ball's in our court.

Note that I'm talking about the core issue: copying some text from another web page or app, then going to a google spreadsheet, and hitting command-v to paste does not have any effect.  You can paste all the text inside a single cell, but that's not the desired outcome.
> Do we really need help from Google here?

Yes.

Keyboard event handling isn't involved here (if it were, things might
actually be easier to figure out).  Instead it's menu handling and
(ultimately) nsPlaintextEditor::InsertText() that's involved (on the
browser side).  At all levels that I can see, the browser's behavior
is correct (i.e. the text that's being "edited" does change as it
should).

So I have to assume that Google is doing something wrong in its
JavaScript code.  But because that code is obfuscated, I haven't
managed to figure out what that is.
Y'all know I'm sure, but, for the record, pasting ain't fixed in beta 5.  Also, now, for me, the rt-click context menu in spreadsheets is mostly not working (ie, sometimes it works, mostly not).  I think there's another bug for this, i'll look around.

Bill

Mac, ox x 5.2, intel

ps.  pasting and rt. clicking does not work in Opera for mac.  Pasting does not work in Ie, but rt. clicking does. (on Windows XP :-) ).  Pasting and rt-clicking works in Safari, except it's easy to confuse Safari, so that when you click on a cell you get the cell two cells above.  Of course, everything continues to work fine in ff 2.0.0.13.
My work in bug 398514 fixes this bug.
Depends on: 398514
Assignee: smichaud → joshmoz
Fixed in Gecko 1.9 by the final patch for bug 398514.
Status: NEW → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Flags: in-litmus?
hmm.  It is not fixed in:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040704 Minefield/3.0pre

/b
Try the next build - I committed the change an hour ago.
It's fixed!  wa hoo!
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040804 Minefield/3.0pre. I verified by creating a new Google spreadsheet and cutting and pasting some text in from a web page.
Status: RESOLVED → VERIFIED
https://litmus.mozilla.org/show_test.cgi?id=5244 added to Litmus
Flags: in-litmus? → in-litmus+
Does anyone else have a problem where the SpreadSheet documents begin to require you to press the SpaceBar prior to entering any date.

The specific problem of this ticket _does_ seem to be resolved.  However, after running for some period of time, and with a set of circumstances which I cannot fully communicate, each cell will not take any data until I press spacebar.  After that, the cells behave normally, until I press enter or an arrow key.

The entire process is fairly predictable, and once the problem starts, it remains until I restart my browser.   I am running Minefield.  I will try to do explicit testing from a reboot with a cold-startup of of the browser.   I frequently edit multiple Google Sheets at a time.  I also do much cutting and pasting between NeoOffice and Google.


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041504 Minefield/3.0pre
Please for give my misspelling and typos.  The first line of the last comment ought to be said like this:

"Does anyone else have a problem where the SpreadSheet documents begin to require you to press the Spacebar prior to entering any data?"
I completed the test.  It appears that the problems begin once I have been changing between two firefox windows using Ctrl-` and Ctrl-Shift-`.

Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.