Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When I click the "(play audio CAPTCHA)" link in Chrome, I just get a white area when the audio player should be. Chrome Version: 2.0.172.33
When I click the "(play audio CAPTCHA)" link in FireFox, I just get a box with a blue lego icon. When I click it, it does a plugin search and tells me "No suitable plugins were found. Unknown Plugin (audio/mp3)." FireFox Version: 3.0.11
Testing on this page:
http://sandbox.brianstevenson.com/comment/reply/161
2 error files attached.
Comment | File | Size | Author |
---|---|---|---|
#48 | mollom-HEAD.audio_.42.patch | 1.05 KB | sun |
#42 | mollom-DRUPAL-6--1.audio_.42.patch | 1.06 KB | sun |
#40 | mollom-HEAD.audio_.40.patch | 7.33 KB | sun |
#39 | mollom-DRUPAL-6--1.audio_.39.patch | 946 bytes | sun |
#38 | captcha-player.patch | 7.37 KB | Dries |
Comments
Comment #1
Dave ReidYou must need to install some kind of mp3-handling plugin like Quicktime or Windows Media Player. It works just fine for me on both the latest Chrome and Firefox 3.5 on Vista for me.
Comment #2
jasonabc CreditAttribution: jasonabc commentedI'm getting this also - I'm running Firefox 3 and IE 8 on Windows XP Professional 64bit. I have Windows Media Player set up as the default player for MP3. Firefox displays the blue box and goes off to the plugin finder (and it can't find any). IE doesn't do anything other than change the link. No audio is ever heard.
Comment #3
te-brian CreditAttribution: te-brian commentedWe're also having mollom audio issues.
When I try it in Safari 4 I get an error:
We've had user reports of similar issues in Firefox 3 and Internet Explorer 8.
Comment #4
patcon CreditAttribution: patcon commentedSame issue here on FF3.5 and Chrome 4... Great module, but this kind of ruins that accessibility options of it, which is pretty key.
Comment #5
patcon CreditAttribution: patcon commentedCorrection: FF3
Comment #6
patcon CreditAttribution: patcon commentedOy... I suck.
Official answer = Doesn't work in FF3 (get the unknown plugin dialog that's screencapped above), but in Chrome 4, works, but audio player is in a tiny scrolling box that's formatted all wacky (see screenshot)
Comment #7
patcon CreditAttribution: patcon commentedErm. Ignore everything I've said here -- need to post a new issue under
6.x-1.10
Goodnight world.
Comment #8
ssace CreditAttribution: ssace commentedI am also having the "missing plugin" problem in Firefox. The audio works in IE8 but not FF.
Can't figure out problem in FF...I have quicktime and windows media plugins installed in FF.
What is the exact extension used for the Mollom audio files? This may help find a plugin that
will work in FF.
Comment #9
Dries CreditAttribution: Dries commentedIt is an MP3 file with extension ".mp3".
Can we detect if the client has the ability to play mp3s? If so, we could consider hiding the audio CAPTCHA when it is not supported.
Comment #10
Dave ReidYeah I've never had this problem with plugins not being able to play MP3s. Maybe we should look into considering a flash-delivery system for the audio CAPTCHAs?
Comment #11
ssace CreditAttribution: ssace commentedFlash would be better...more compatible with different browsers. I'm running Win7 x64 and I can only figure
that the .mp3 plugin for FF is not working.
To find if you have a plugin associated with .mp3, type about:plugins in FF browser. I set the MIME type in quicktime
to handle .mp3 in my browser but for some reason it's not working. The quicktime plugin I have is probably to old
for Win7 64 bit operating system.
Comment #12
patcon CreditAttribution: patcon commentedAh... I'm running WinXP x64... so maybe that's the issue. I'll try on a different system when I get the chance.
Comment #13
Dave ReidPlease let us know what you find with MP3 + Win x64. I'll add Flash delivery to our internal feature list since it's not anything we can handle with the Module itself.
Comment #14
patcon CreditAttribution: patcon commentedI'm out of the office, but I've got it on my to-do list for when I get back :)
Comment #15
mhaag CreditAttribution: mhaag commentedI can reproduce the problem with FF 3.5.6 and XP (SP3, 32bit). Specifically, when I select the "play audio verification" link for the captcha using FF, I receive a prompt to install a missing plug-in. When Firefox attempts to find and install the 'missing' plug-in, I receive a message that "No suitable plug-ins were found". However, I have verified that my FF settings use a valid plugin for mp3's (QuickTime), and I verified that FF can play mp3s (eg I can open a local mp3 file from FF and it plays fine, within the browser). I also tried configuring FF to use Windows Media Player to play mp3's, but Mollom fails in the same way with that setting.
I have colleagues (and a customer) that can reproduce this behavior.
Comment #16
mhaag CreditAttribution: mhaag commentedsee similar issue at http://drupal.org/node/650320.
Comment #17
Dries CreditAttribution: Dries commentedWe currently use in
mollom.pages.inc
:1. The following Adobe article seems to be a good resource and it should be fairly easy to implement: http://kb2.adobe.com/cps/415/tn_4150.html (The article is about Flash, but the same might be true for MP3s.)
2. From http://digitalmedia.oreilly.com/2005/02/23/mp3_embed.html : Unfortunately, the embed tag was never officially accepted into the HTML specification, and many browsers (notably Internet Explorer) went with the object tag instead. So to handle both cases, we wrap the embed tag in an object tag with the same parameters and values.
I don't have a Windows machine so I can't play around with this. Anyone cares to give this a try? Should be easy.
Comment #18
Dave ReidOk let me throw together a page of test mp3 HTML and post the link here. Everyone can report which works for them and we'll move forward and fix this.
Comment #19
Dave ReidWill be posting the test page today...
Comment #20
Dave ReidCould I get everyone to test this page and report back which options worked in their browser and which browser you were using?
http://dl.dropbox.com/u/840794/mp3test.html
Comment #21
gavin_o CreditAttribution: gavin_o commentedHi,
All three played for me in Firefox and Chrome (Windows). In Chrome only, options 1 & 2 autoplayed.
Comment #22
Dries CreditAttribution: Dries commentedAll 3 worked for me on Firefox 3 on the Mac. We can't really use the Google player IMO, but maybe it is just included for testing-purposes.
Comment #23
Dave ReidYeah, don't be concerned about auto-playing. None of them should autoplay, otherwise you'd have three files going off at once. Yeah, Google Flash player was just a test to see if it worked.
Some more alternate options would be:
Flow Player (Flash)
jQuery Media
Comment #24
te-brian CreditAttribution: te-brian commentedUsing FF 3.5.7. Windows 7.
The first two prompted a Quicktime update. I chose NOT to update and the audio embed is just a black box. Loading the page again did not prompt the update a second time. The embeds remain as black boxes. They did not autoplay.
In Chrome, the update was not prompted and they remain as black boxes. They did autoplay in Chrome.
In Safari the top two show up as broken plugin boxes (box with a ? in it). They did not autoplay.
In IE8 all three players show up as black boxes. No autoplay.
To reiterate, this is after intentionally saying "no" to the quicktime update. I can't get it to ask me for the update automatically again, but I will manually update later and report in.
Comment #25
ssace CreditAttribution: ssace commentedUsing latest Firefox...
All 3 works for me. Nothing auto-played for me.
I already had quicktime plugin installed on my browser.
Comment #26
patcon CreditAttribution: patcon commentedUsing Chrome 4.0.295.0 dev (Windows vista)
Option 1 & 2 autoplayed, but still looked like the attachment in #6
Option 3 rendered correctly, but didn't autoplay.
Comment #27
Dave Reid"Yeah, don't be concerned about auto-playing. None of them should autoplay, otherwise you'd have three files going off at once."
We just want to know which ones can play. :)
Comment #28
patcon CreditAttribution: patcon commentedOh hey, they all played then :)
Comment #29
elsuertudo CreditAttribution: elsuertudo commentedIm on Windows XP Home Edition SP3 with all the latest browser updates. These are the results I'm getting:
Firefox
----------------------------------------------
All play correctly when button pushed
IE6 (IEtester version), IE8 emulating IE7, IE8
----------------------------------------------
1,2 play correctly when button pushed
Player 3 won't render
Opera
----------------------------------------------
All play correctly when button pushed
Safari
----------------------------------------------
Throws an error on 1 and 2 saying it can't show the content as MIME type is not specified. Players wont render.
3 plays correctly when button pushed
Chrome
----------------------------------------------
1,2 autoplay
3 plays correctly when button pushed
Comment #30
sunHm. Not as easy as I thought.
Testing attached patch on Windows:
IE6 and IE7 work flawlessly for me.
IE8 asks to install the "Windows Media Player Core from Microsoft Corporation" add-on.
Chrome asks to install a plugin, QuickTime player. Need to test whether changing the mime-type makes a difference.
Firefox 3.5 equally tells that a plugin is required, fails to identify which plugin could help. (i.e. not even an option to install one)
Opera 9 doesn't prompt for a missing plugin at all, clicking the placeholder opens a new tab: http://www.opera.com/support/kb/plug-ins/page1/ (very helpful...)
Safari 4 prompts for a missing plugin and blows me away with a variety of options to install: http://www.apple.com/safari/download/plugins.html?audio%2Fmpeg
Comment #31
Dries CreditAttribution: Dries commentedsun and I briefly talked about this and we agreed that making a small Mollom-specific player in Flash would be the best solution. sun is going to look into this.
Comment #32
sunUsing a Flash-based solution will resolve all of the mime-type, codec, platform, player, and browser plugin issues. The only dependency will be Flash, but considering that many websites contain Flash content these days, it's far more likely that site visitors have a Flash-plugin installed. Same applies to public terminals and mobile devices.
So let's look at what we have currently:
I originally envisioned that we could replace the image captcha with an equally looking audio captcha:
However, Dries just noted that paid subscribers to Mollom don't get the Mollom logo in the captcha. So I reconsidered and will post the second iteration soon.
Comment #33
sunSo my next best idea was to extend the entire widget, also taking #502390: Added Refresh Captcha Option in Mollom module into consideration:
However, this would mean that we'd have to issue XML-RPC requests for the audio captcha mp3 URL when presenting the image captcha already, so this idea is basically dead already.
Comment #34
patcon CreditAttribution: patcon commentedOooooooohhhh... pretty...
Comment #35
Dave ReidWell it'll work on everything except for things like the iPad. </apple sarcasm> :)
Looking great and +1 for this direction!
Comment #36
sunNow flashy.
Comment #37
sunTemporarily hosted on unleashedmind.com, because .swf attachments are not allowed on d.o.
I used the literal NOSCRIPT output of Flash's template code. That "should" work. What we may want to (re)consider is the minimum required Flash version - this .swf is based on ActionScript 3. To be compatible with lower Flash versions, we need to rewrite it for ActionScript 2...
Comment #38
Dries CreditAttribution: Dries commentedGreat work sun, and thanks for the help Dave.
I decided to add the player to CVS because hosting it on mollom.com creates a single point of failure which defeats our client-side load balancing.
Hence, I modified the patch in #37, and committed it to CVS HEAD. The modified patch is also attached for reference.
Comment #39
sunSorry, not sure how why I didn't remove that debug line.
Comment #40
sunPorted to HEAD.
Reminder:
1) Patch in #39 for D6.
2) Also add the .swf to HEAD.
3) Attached patch is for HEAD.
Comment #41
Dave ReidWe shouldn't be doing
url(drupal_get_path('module', 'mollom') . '/mollom-captcha-player.swf'
since this will break on non-clean URLs.Please use
base_path() . drupal_get_path('module', 'mollom') . '/mollom-captcha-player.swf'
Comment #42
sunTrue. This patch is for D6, but should also apply cleanly on HEAD after applying or committing #40.
Comment #43
Dave ReidThat's interesting how that works with external => TRUE. Usually I don't use url() at all since that's how core creates links to CSS and JS files.
Comment #44
Dave ReidSorry.
Comment #45
sunYes. We should still use url(), due to the query string we need to append.
Comment #46
Dries CreditAttribution: Dries commentedCommitted to DRUPAL-6--1. Moving to D7.
Comment #47
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD too.
Comment #48
sun#42 once more for HEAD.
Comment #49
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD.
Comment #51
trothwell CreditAttribution: trothwell commentedRe-Opening as the Audio CAPTCHA still doesn't work. Appears as though the encoding of the url is either:
A) Not encoded correctly by url()
B) Not handled correctly by the swf player
Doing a quick hack to bypass the url function obvious fixes it but bypasses the XSS encoding.
Comment #52
sun#51 has been fixed in the 2.x series already, so reverting the status of this issue.