2011-04-14 00:15:48 +02:00
|
|
|
<?php
|
|
|
|
|
2014-07-10 00:12:48 +02:00
|
|
|
final class PhabricatorRemarkupRuleImageMacro extends PhutilRemarkupRule {
|
2011-04-14 00:15:48 +02:00
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
private $macros;
|
|
|
|
|
|
|
|
const KEY_RULE_MACRO = 'rule.macro';
|
2011-04-14 00:15:48 +02:00
|
|
|
|
|
|
|
public function apply($text) {
|
2013-02-22 01:13:55 +01:00
|
|
|
return preg_replace_callback(
|
2014-05-05 20:23:12 +02:00
|
|
|
'@^\s*([a-zA-Z0-9:_\-]+)$@m',
|
2011-04-14 00:15:48 +02:00
|
|
|
array($this, 'markupImageMacro'),
|
|
|
|
$text);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function markupImageMacro($matches) {
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
if ($this->macros === null) {
|
|
|
|
$this->macros = array();
|
2013-03-22 21:07:20 +01:00
|
|
|
|
|
|
|
$viewer = $this->getEngine()->getConfig('viewer');
|
|
|
|
$rows = id(new PhabricatorMacroQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withStatus(PhabricatorMacroQuery::STATUS_ACTIVE)
|
|
|
|
->execute();
|
2013-09-28 01:02:02 +02:00
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$this->macros = mpull($rows, 'getPHID', 'getName');
|
2012-07-11 20:40:10 +02:00
|
|
|
}
|
|
|
|
|
2013-02-13 23:50:15 +01:00
|
|
|
$name = (string)$matches[1];
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
if (empty($this->macros[$name])) {
|
|
|
|
return $matches[1];
|
|
|
|
}
|
2013-02-13 23:50:15 +01:00
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$engine = $this->getEngine();
|
2011-04-14 00:15:48 +02:00
|
|
|
|
2013-03-23 01:33:36 +01:00
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$metadata_key = self::KEY_RULE_MACRO;
|
|
|
|
$metadata = $engine->getTextMetadata($metadata_key, array());
|
|
|
|
|
|
|
|
$token = $engine->storeText('<macro>');
|
|
|
|
$metadata[] = array(
|
|
|
|
'token' => $token,
|
|
|
|
'phid' => $this->macros[$name],
|
|
|
|
'original' => $name,
|
|
|
|
);
|
|
|
|
|
|
|
|
$engine->setTextMetadata($metadata_key, $metadata);
|
|
|
|
|
|
|
|
return $token;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function didMarkupText() {
|
|
|
|
$engine = $this->getEngine();
|
|
|
|
$metadata_key = self::KEY_RULE_MACRO;
|
|
|
|
$metadata = $engine->getTextMetadata($metadata_key, array());
|
|
|
|
|
|
|
|
if (!$metadata) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$phids = ipull($metadata, 'phid');
|
|
|
|
$viewer = $this->getEngine()->getConfig('viewer');
|
|
|
|
|
|
|
|
// Load all the macros.
|
|
|
|
$macros = id(new PhabricatorMacroQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withStatus(PhabricatorMacroQuery::STATUS_ACTIVE)
|
|
|
|
->withPHIDs($phids)
|
|
|
|
->execute();
|
|
|
|
$macros = mpull($macros, null, 'getPHID');
|
|
|
|
|
|
|
|
// Load all the images and audio.
|
|
|
|
$file_phids = array_merge(
|
|
|
|
array_values(mpull($macros, 'getFilePHID')),
|
|
|
|
array_values(mpull($macros, 'getAudioPHID')));
|
|
|
|
|
|
|
|
$file_phids = array_filter($file_phids);
|
|
|
|
|
|
|
|
$files = array();
|
|
|
|
if ($file_phids) {
|
|
|
|
$files = id(new PhabricatorFileQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withPHIDs($file_phids)
|
|
|
|
->execute();
|
|
|
|
$files = mpull($files, null, 'getPHID');
|
|
|
|
}
|
|
|
|
|
|
|
|
// Replace any macros that we couldn't load the macro or image for with
|
|
|
|
// the original text.
|
|
|
|
foreach ($metadata as $key => $spec) {
|
|
|
|
$macro = idx($macros, $spec['phid']);
|
|
|
|
if ($macro) {
|
|
|
|
$file = idx($files, $macro->getFilePHID());
|
2013-03-23 01:33:36 +01:00
|
|
|
if ($file) {
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
continue;
|
2013-03-23 01:33:36 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$engine->overwriteStoredText($spec['token'], $spec['original']);
|
|
|
|
unset($metadata[$key]);
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($metadata as $spec) {
|
|
|
|
$macro = $macros[$spec['phid']];
|
|
|
|
$file = $files[$macro->getFilePHID()];
|
|
|
|
$src_uri = $file->getBestURI();
|
|
|
|
|
|
|
|
if ($this->getEngine()->isTextMode()) {
|
|
|
|
$result = $spec['original'].' <'.$src_uri.'>';
|
|
|
|
$engine->overwriteStoredText($spec['token'], $result);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
$file_data = $file->getMetadata();
|
2013-01-27 03:59:35 +01:00
|
|
|
$style = null;
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$height = idx($file_data, PhabricatorFile::METADATA_IMAGE_HEIGHT);
|
|
|
|
$width = idx($file_data, PhabricatorFile::METADATA_IMAGE_WIDTH);
|
|
|
|
if ($height && $width) {
|
|
|
|
$style = sprintf(
|
|
|
|
'height: %dpx; width: %dpx;',
|
|
|
|
$height,
|
|
|
|
$width);
|
2012-01-10 23:48:55 +01:00
|
|
|
}
|
2011-04-14 00:15:48 +02:00
|
|
|
|
2013-09-28 01:02:02 +02:00
|
|
|
$id = null;
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$audio = idx($files, $macro->getAudioPHID());
|
|
|
|
if ($audio) {
|
2013-09-28 01:02:02 +02:00
|
|
|
$id = celerity_generate_unique_node_id();
|
|
|
|
|
|
|
|
$loop = null;
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
switch ($macro->getAudioBehavior()) {
|
2013-09-28 01:02:02 +02:00
|
|
|
case PhabricatorFileImageMacro::AUDIO_BEHAVIOR_LOOP:
|
|
|
|
$loop = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
Javelin::initBehavior(
|
|
|
|
'audio-source',
|
|
|
|
array(
|
|
|
|
'sourceID' => $id,
|
|
|
|
'audioURI' => $audio->getBestURI(),
|
|
|
|
'loop' => $loop,
|
|
|
|
));
|
2013-09-28 01:02:02 +02:00
|
|
|
}
|
|
|
|
|
2014-07-01 20:04:05 +02:00
|
|
|
$result = $this->newTag(
|
2011-04-14 00:15:48 +02:00
|
|
|
'img',
|
|
|
|
array(
|
2013-09-28 01:02:02 +02:00
|
|
|
'id' => $id,
|
2012-01-10 23:48:55 +01:00
|
|
|
'src' => $src_uri,
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
'alt' => $spec['original'],
|
|
|
|
'title' => $spec['original'],
|
2013-01-27 15:01:27 +01:00
|
|
|
'style' => $style,
|
2013-01-18 03:39:02 +01:00
|
|
|
));
|
2013-09-28 01:02:02 +02:00
|
|
|
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
$engine->overwriteStoredText($spec['token'], $result);
|
2011-04-14 00:15:48 +02:00
|
|
|
}
|
Fix two issues with audio macros
Summary:
Fixes T3887. Two issues:
- Macros were generating entirely before the render cache, so audio macros worked fine in previews and the first time the cache was populated, but not afterward.
- Instead, parse them before the cache but drop them in after the cache. Clean up all the file querying, too. This makes cached remarkup generate the correct audio beahviors.
- Safari sends an HTTP request with a "Range" header, and expects a "206 Partial Content" response. If we don't give it one, it sometimes has trouble figuring out how long a piece of audio is (mostly for longer clips? Or mostly for MP3s?). I'm not exactly sure what triggers it. The net effect is that "loop" does not work when Safari gets confused. While looping a short "quack.wav" worked fine, longer MP3s didn't loop.
- Supporting "Range" and "206 Partial Content", which is straightforward, fixes this problem.
Test Plan:
- Viewed a page with lots of different cached audio macros and lots of different uncached preview audio macros, they all rendered correctly and played audio.
- Viewed a macro with a long MP3 audio loop in Safari. Verified it looped after it completed. Used Charles to check that the server received and responded to the "Range" header correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3887
Differential Revision: https://secure.phabricator.com/D7166
2013-09-29 00:32:48 +02:00
|
|
|
|
|
|
|
$engine->setTextMetadata($metadata_key, array());
|
2011-04-14 00:15:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|