Closed Bug 681922 Opened 14 years ago Closed 13 years ago

In google docs Upload -> Files has no highlighting

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: sbadau, Unassigned)

References

Details

(Keywords: qawanted, verified-beta, Whiteboard: [qa+][qa!:9])

Attachments

(1 file)

Screenshot of the issue
37.27 KB, image/jpeg
Details
Mozilla/5.0 (Windows NT 6.0; rv:7.0) Gecko/20100101 Firefox/7.0 When uploading in google docs "Files" menu item - is not highlighted. Reproducible: always Steps to reproduce: 1. Log into your Gmail account and select Documents. 2. Click on Upload. Actual results: Although files can be uploaded, "Files" menu item is not highlighted when moving the mouse over it. Expected results: "Files" menu item is highlighted.
Reproduced: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (X11; Linux x86_64; rv:8.0a2) Gecko/20110825 Firefox/8.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110825 Firefox/9.0a1 Works for me: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1 Menu looks completely different: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.50
Hardware: x86 → All
Version: 7 Branch → Trunk
If I use User Agent RG 1.0, faking "Mozilla/5.0 (compatible) AppleWebKit/534.21 (KHTML, like Gecko) Chrome/11.0.682.0 Safari/534.21", then "Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110825 Firefox/9.0a1" becomes a Works For Me.
Doing the other way around: $ chromium-browser --user-agent="Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110825 Firefox/9.0a1" Then I can reproduce the bug. So it looks like Google Docs does user agent sniffing and then let the menu behave badly when they think the site is visited by a Firefox browser.
This could be a Tech Evangelism bug. Going to ask for tracking to raise visibility.
tracking-firefox7: --- → ?
tracking-firefox8: --- → ?
tracking-firefox9: --- → ?
Contacting some Google people to check.
Google people contacted.
Any word?
They said they were looking into it. I just followed up again.
Untracking this for Firefox 7 as it exists in earlier versions and is a Google problem most likely.
tracking-firefox7: + → ---
One of the Google guys says they are escalating it. (Not sure what that means, exactly, but it's an email response!)
Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20100101 Firefox/8.0 This issue is still reproducible on Firefox 8 beta 2.
Reproducible for me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Hi Simona and Vlad. This is more than likely a Google issue. We expect this bug to ride-along with every release until Google patches the issue on their end; at which point we will have to re-evaluate if it's still an issue in Firefox. Thanks
Issue can still be seen in Firefox 9 beta 1. Mozilla/5.0 (Windows NT 6.0; rv:9.0) Gecko/20100101 Firefox/9.0
With the new Google+ UI I do not see this issue in Firefox 9.0b2. Please confirm if this is still reproducible.
I can still reproduce this issue on 9b2 with Google+ UI
Please provide a screencast because I can't reproduce this at all.
Dropping to UNCONFIRMED until we can pinpoint what, if anything, is happening.
Status: NEW → UNCONFIRMED
Ever confirmed: false
I'm a bit perplexed because a community member was able to reproduce this yesterday on Windows 7 64-bit with Firefox 9.0b4. Simona, can you please attach a screencast to this bug so I can see what you are seeing? Maybe I am looking for the wrong thing.
Keywords: qawanted
Attached image Screenshot of the issue —
Okay, thanks, I am now seeing this. I was indeed looking at the wrong thing. Something I noticed is not only does this not get highlighting, the cursor is a text-cursor, not a link cursor like the other menu items. Simona, can you use the moz-regression tool to see if this is a regression?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted → regressionwindow-wanted
Issue is reproducible ever since Firefox 3.6.16. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 The highlight is also missing on other browsers (Opera 11.52 and IE 8) with the exception that the cursor is a link cursor not a text cursor as in Firefox. This behavior is not encountered in Chrome 15.0.874.121 or Safari 5.0.5.
So it looks like WebKit browsers are fine -- browsers using other rendering engines are not. Using the Inspector I noticed that the Files... item is different than all others. Files... is an <input> field Others are <div> with goog-menuitem class Simona, could you create a minimized HTML testcase for this menu and attach it to this bug?
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Keywords: regressionwindow-wanted
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #23) > So it looks like WebKit browsers are fine -- browsers using other rendering > engines are not. And as I pointed out in comment 2 - this depends on the user agent string. Pretend to be WebKit, and Firefox works as well.
Could this be a Tech Evangelism issue then? If all it takes is changing a user agent string then this must be server-side and not a Firefox bug -- or am I incorrect?
Well, they could be sending us different content that we're still rendering incorrectly ...
Kyle, any advice on next steps for QA to investigate/escalate this issue?
We should figure out what the difference in between what WebKit is getting served and what Firefox is getting served is. From there we can determine if this is us choking on different content, or them sending us broken content.
Any advice how we can do that?
Um... Save both pages and compare them? That's the normal way one does it. If they're identical, then look through the scripts to see where they UA-sniff. Looking at the page, they send various -moz styles to us when we're not spoofing the WebKit UA, so there may in fact be a relevant difference here.
In any case, I contacted Google about this; hopefully they can just point us to what they're doing differently.
Thanks Boris. I have looked at the HTML source and this sub-menu is not in the source. It must be dynamically generated by a script or something.
I'm assuming you looked at the "save page, complete" source, right? If I "save page, complete", then that particular menuitem is not present, but others are; is the menu in the source at that point or is it still being generated entirely in JS?
I think it is pure JS. I think the menu source code you can see is for the side menu. I cannot find the source for the sub-menu contained within the Upload button.
Response from Google: This is a Docslist issue. We put a flash overlay on top of that item and we aren't propagating the hover event to the underlying UI component (a menu item). It's on my plate to fix but keeps getting pushed down by other priorities. I'll see what I can do to escalate.
Assignee: nobody → english-us
Component: Layout → English US
Product: Core → Tech Evangelism
QA Contact: layout → english-us
Version: Trunk → unspecified
Nice. Thanks Boris.
Further followup: I just spoke with the person who implemented this originally and he corrected me. It's not a flash overlay, but rather a input of type "file" that we overlay. The reason was lack of programmatic invocation of the file browsing dialog. In Safari and Chrome, this was exposed programmatically, but on Firefox as of the time this component was written, there was no programmatic access and so we invoked using an overlay. The issue around catching and propagating the hover is similar to what I described before.
Got some news from Google. Apparently, this has been fixed internally and it should visible next week (the 15th of December).
I have test this and the issue is fixed on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6 Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6 Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 beta 6 The "Files" menu item is now highlighted. Setting resolution to Verified Fixed on Beta.
Keywords: verified-beta
Whiteboard: [qa+][qa!:9]
The "Files..." menu is now highlighted in nightly as well. Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111215 Firefox/11.0a1
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 Issue is reproducible again on Firefox 11 beta 1 - the File option is not highlighted.
Reproduced. The bug is back again. :-( Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (X11; Linux x86_64; rv:11.0a2) Gecko/20120131 Firefox/11.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120202 Firefox/13.0a1
Yes. Google apparently backed out their fix...
Depends on: 709448
Jonas suggests in https://bugzilla.mozilla.org/show_bug.cgi?id=709448#c21 that uploading on Google Docs is broken due to this bug. Can anybody confirm that's the case? Adding qawanted keyword.
Keywords: qawanted
I can still upload files. It just doesn't change the cursor to the typical "link hand". You can still click and upload files. At least on my end.
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 Same here. The menu is still broken, but I can upload anyway.
This issue seems to be fixed with the latest Nightly. User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:20.0) Gecko/20.0 Firefox/20.0 Build ID: 20121120030739
Manuela, can you please also check the latest Beta, Aurora, and Release? Is this something they fixed on their end?
This issue is also fixed on the latest Beta, Aurora, and Release. Firefox 18 beta 1: User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121121075611 Aurora : User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121121042014 Firefox 17 Release User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 20121119183901 It's possible they fixed it since they had already fixed it once before (but it regressed again).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: