Closed
Bug 601064
Opened 14 years ago
Closed 14 years ago
"Listen" buttons in google translate not working
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla2.0
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: Surfer56, Assigned: roc)
References
()
Details
(Keywords: regression, Whiteboard: [hardblocker])
Attachments
(3 files, 1 obsolete file)
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•14 years ago
|
||
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
Comment 2•14 years ago
|
||
(In reply to comment #1)
Please ignore above.
Ah. LEFT side of "Listen" does not work too.
Comment 3•14 years ago
|
||
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
Keywords: regression,
regressionwindow-wanted
Target Milestone: --- → Firefox 4.0
Version: unspecified → Trunk
Comment 4•14 years ago
|
||
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; }
Blocks: 522394
Keywords: regressionwindow-wanted
Updated•14 years ago
|
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Target Milestone: Firefox 4.0 → mozilla2.0
Comment 5•14 years ago
|
||
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 | ||
Updated•14 years ago
|
Assignee: nobody → roc
Assignee | ||
Comment 6•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 years ago
|
||
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
Comment 8•14 years ago
|
||
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).
Assignee | ||
Comment 9•14 years ago
|
||
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.
Comment 10•14 years ago
|
||
In async mode we can probably call setwindow/WM_WINDPOSCHANGED without actually painting, if that's preferable.
Assignee | ||
Comment 11•14 years ago
|
||
Sure, that's probably fine.
Comment 12•14 years ago
|
||
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.
Comment 16•14 years ago
|
||
Both left and right buttons are not working for me.
Updated•14 years ago
|
Summary: Left "Listen" button in google translate not working → "Listen" buttons in google translate not working
Assignee | ||
Comment 17•14 years ago
|
||
Hmm, we are generating a WM_WINDOWPOSCHANGED event for the plugins now; every time we get an AsyncSetWindow, PluginInstanceChild::UpdateWindowAttributes dispatches a WM_WINDOWPOSCHANGED.
Assignee | ||
Comment 18•14 years ago
|
||
Attachment #499997 -
Flags: review?
Assignee | ||
Updated•14 years ago
|
Attachment #499997 -
Flags: review? → review?(benjamin)
Assignee | ||
Comment 19•14 years ago
|
||
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)
Assignee | ||
Comment 20•14 years ago
|
||
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...
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review]
Comment 21•14 years ago
|
||
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+
Updated•14 years ago
|
Attachment #500000 -
Flags: review?(benjamin) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Comment 22•14 years ago
|
||
I landed this, but backed out due to test failures:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1294114775.1294115479.31741.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1294114826.1294115550.31973.gz
Assignee | ||
Comment 23•14 years ago
|
||
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Updated•14 years ago
|
Whiteboard: [hardblocker]
Assignee | ||
Comment 24•14 years ago
|
||
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.
Comment 25•14 years ago
|
||
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.
Assignee | ||
Comment 26•14 years ago
|
||
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)
Assignee | ||
Comment 27•14 years ago
|
||
Updated tests to not make assumptions about OOPP etc.
Attachment #502721 -
Flags: review?(benjamin)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [hardblocker] → [hardblocker][needs review]
Updated•14 years ago
|
Attachment #502720 -
Flags: review?(benjamin) → review+
Updated•14 years ago
|
Attachment #502721 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 28•14 years ago
|
||
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: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [hardblocker][needs review] → [hardblocker]
Comment 29•14 years ago
|
||
Verified - Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Comment 30•14 years ago
|
||
FYI
annotation is wrong.
cset 27c92be3d840 is for Bug 519144.
Comment 31•14 years ago
|
||
why this is so hard to fix?
Assignee | ||
Comment 32•14 years ago
|
||
It is fixed.
Comment 33•14 years ago
|
||
No... its not fixed for me!
Firefox 4.0.1
Assignee | ||
Comment 34•14 years ago
|
||
Works for me on Windows 7. You should file a new bug I guess.
Comment 35•14 years ago
|
||
@Robert, they will mark as duplicated =/
Win7 64
FF 4.0.1
Name: Firefox de Gald no Windows NT 6.1; WOW64
Assignee | ||
Comment 36•14 years ago
|
||
No, because this bug is fixed and your bug is not so they're clearly not duplicates.
Comment 37•14 years ago
|
||
@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.
Comment 38•12 years ago
|
||
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.
Comment 39•12 years ago
|
||
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.
Comment 40•12 years ago
|
||
(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.
Description
•