Closed Bug 601064 Opened 9 years ago Closed 9 years ago

"Listen" buttons in google translate not working

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: Surfer56, Assigned: roc)

References

(Depends on 1 open bug, )

Details

(Keywords: regression, Whiteboard: [hardblocker])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre

Left "Listen" button in google translate not working

Reproducible: Always

Steps to Reproduce:
1. go to http://translate.google.com/
2. type some words
3. click "Listen" button
Actual Results:  
nothing happens

Expected Results:  
voice from gtranslate
WFM

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre ID:20100930041305

Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre ID:20100930041305
(In reply to comment #1)
Please ignore above.

Ah. LEFT side of "Listen" does not work too.
Maybe this problem is only windows, because it works on Linux build.

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/5f0bd7129549
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091026 Minefield/3.7a1pre ID:20091026045849
Fails:
http://hg.mozilla.org/mozilla-central/rev/2e01e97f9ded
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre ID:20091027043823
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5f0bd7129549&tochange=2e01e97f9ded
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Target Milestone: --- → Firefox 4.0
Version: unspecified → Trunk
The following changeset causes the problem.

27c92be3d840	Robert O'Callahan — Bug 522394. Don't bother descending into zero-opacity content when constructing display list. r=dbaron]

WORKAROUND: append the folowing CSS to userContent.css. 
* { opacity:1 !important; }
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Target Milestone: Firefox 4.0 → mozilla2.0
Given the contents of http://hg.mozilla.org/mozilla-central/rev/27c92be3d840 , I tend to suspect aBuilder->IsForEventDelivery() isn't actually returning what it's supposed to.
blocking2.0: ? → betaN+
Assignee: nobody → roc
There's an element input_tts_button which is opacity:0 and contains a transparent Flash object sound_player2.swf.

It turns out that the Flash object needs to receive the WM_WINDOWPOSCHANGED event that nsObjectFrame::PaintPlugin sends. If it doesn't get that event, it doesn't work. Weird.
Benjamin, does bug 596451 fix this? I'm guessing it would because we must be generating WM_WINDOWPOSCHANGED events in plugin-container.exe even if the plugin is invisible in the browser.
Depends on: 596451
It might. However, I plan on doing a followup so that we don't ask the plugin to paint if it's not visible (especially important for background flash videos and animations, which currently in async mode continue to send paint updates).
OK, to keep this bug fixed I think we'll just need to ensure that we ask it to paint once at the beginning even if it's not visible.
In async mode we can probably call setwindow/WM_WINDPOSCHANGED without actually painting, if that's preferable.
Sure, that's probably fine.
Note, the current patches series in maple which is almost ready to commit doesn't fix this bug. We send a NPP_SetWindow, but not a WM_WINDOWPOSCHANGED message when a plugin is invisible.
Blocks: 607213
No longer blocks: 607213
Duplicate of this bug: 612686
Duplicate of this bug: 612686
Duplicate of this bug: 612686
Blocks: 611635
Both left and right buttons are not working for me.
Summary: Left "Listen" button in google translate not working → "Listen" buttons in google translate not working
Hmm, we are generating a WM_WINDOWPOSCHANGED event for the plugins now; every time we get an AsyncSetWindow, PluginInstanceChild::UpdateWindowAttributes dispatches a WM_WINDOWPOSCHANGED.
Attachment #499997 - Flags: review? → review?(benjamin)
Attached patch Updated testSplinter Review
Update test to account for extra initial paint for a fully-clipped plugin. This serves as a testcase for this change.
Attachment #500000 - Flags: review?(benjamin)
As far as I can tell, the Google Translate Flash instance needs to get both a WM_WINDOWPOSCHANGED and a WM_PAINT before it will correctly process the scripted commands sent by the rest of the application.

I don't know if "you will always get at least one WM_PAINT" is something that should be part of the NPAPI contract, but I guess we don't have much choice...
Whiteboard: [needs review]
Comment on attachment 499997 [details] [diff] [review]
Ensure we ask each plugin instance to paint at least once. Some plugin instances assume they will be asked to paint even if they're always invisible

Ugh.
Attachment #499997 - Flags: review?(benjamin) → review+
Attachment #500000 - Flags: review?(benjamin) → review+
Whiteboard: [needs review] → [needs landing]
Whiteboard: [needs landing]
Whiteboard: [hardblocker]
The painting failures on Linux are because we we ask plugins to paint while they're invisible. In nptest_gtk2.cpp pluginHandleEvent we have
    if (expose.x < clip.left || expose.y < clip.top ||
        expose.x + expose.width > clip.right ||
        expose.y + expose.height > clip.bottom) {
      g_warning("expose rectangle not in clip rectangle");
      return 0;
This runs and the plugin doesn't paint anything. But the browser thinks the plugin surface is up to date and reuses it later.

I'm not yet sure what to do here. I suppose we need to pretend the plugin is visible until it has painted once, then tell it it's not visible.
The nature of the painting and visibility APIs means that the plugin must be "visible" to paint anything.  That is on Linux, at least.  The clipRect situation with GDI plugins is very vague.

I assume the paint added here just needs to be a paint event and so could possibly have an empty expose rect.  Even the paint event may not be necessary on Linux.
Attached patch Part 1 v2Splinter Review
Added code to PluginInstanceChild::UpdateWindowAttributes to ensure that the clipRect is set to the full window size temporarily during the first paint.
Attachment #499997 - Attachment is obsolete: true
Attachment #502720 - Flags: review?(benjamin)
Attached patch tests v2Splinter Review
Updated tests to not make assumptions about OOPP etc.
Attachment #502721 - Flags: review?(benjamin)
Whiteboard: [hardblocker] → [hardblocker][needs review]
Attachment #502720 - Flags: review?(benjamin) → review+
Attachment #502721 - Flags: review?(benjamin) → review+
http://hg.mozilla.org/mozilla-central/rev/ee45778d91fa
http://hg.mozilla.org/mozilla-central/rev/b287f4a4ba4f

I had to reorganize the patch a little bit; we have to temporarily set the plugin to be visible for the first paint in PaintRectToPlatformSurface. Maybe I should have gotten re-review...
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [hardblocker][needs review] → [hardblocker]
Depends on: 631720
Verified - Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
No longer blocks: 611635
Depends on: 647139
FYI
annotation is wrong.
cset 27c92be3d840 is for Bug 519144.
Blocks: 519144
No longer blocks: 522394
why this is so hard to fix?
No... its not fixed for me!

Firefox 4.0.1
Works for me on Windows 7. You should file a new bug I guess.
@Robert, they will mark as duplicated =/

Win7 64
FF 4.0.1
Name: Firefox de Gald no Windows NT 6.1; WOW64
No, because this bug is fixed and your bug is not so they're clearly not duplicates.
@Robert, now i know, the problem is with the flashblock, i need to disabled it.
thx, i will try to contact the developers of this extension.
Back to the initial problem concerning "Listen" buttons in Google Translate. It is once again actual.

System: 
Windows XP Sp3 Rus Home Edition (but according to the discussion on Russian Mozilla support forum, the OS, at least Windows, doesn't matter).

Shockwave Flash:
NPSWF32_11_4_402_265.dll
11.4.402.265
Shockwave Flash 11.4 r402

Results:
In Firefox 16.0a2 audio works only in the Plagin Container allowed mode.
In Firefox 17.0a2 and Firefox 18.0a1 it refuses to work independently on Plagin Container mode. 

Running the browser in Safe Mode does not help: nothing changes. So it is not the extensions or style problem.
In IE8 this function works fine.
Vladimir_S, please open a new bug. This old one is fixed. Please cc me and :johns; I suspect that a recent refactoring of nsObjectLoadingContent re-broke this.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #39)
> Vladimir_S, please open a new bug. This old one is fixed. Please cc me and
> :johns; I suspect that a recent refactoring of nsObjectLoadingContent
> re-broke this.

Done: https://bugzilla.mozilla.org/show_bug.cgi?id=786650
You need to log in before you can comment on or make changes to this bug.