Closed Bug 671479 Opened 14 years ago Closed 12 years ago

Mozmill Endurance test for loading a SWF video via iframe

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(firefox20 fixed, firefox21 fixed, firefox22 fixed, firefox23 fixed, firefox-esr17 fixed)

RESOLVED FIXED
Tracking Status
firefox20 --- fixed
firefox21 --- fixed
firefox22 --- fixed
firefox23 --- fixed
firefox-esr17 --- fixed

People

(Reporter: u279076, Assigned: daniela.p98911)

References

()

Details

(Whiteboard: [mozmill-endurance])

Attachments

(2 files, 4 obsolete files)

Create a Mozmill Endurance test for loading an SWF video embedded into a webpage using the <iframe> tag. An example of how YouTube does this: <iframe width="425" height="349" src="http://url.to.youtube/video" frameborder="0" allowfullscreen></iframe>
For consistency, please use a width of 640 and a height of 480.
That will work with flash content? I would be surprised.
(In reply to comment #2) > That will work with flash content? I would be surprised. Yes, I've tested it locally and it works. Simply replace the youtube URL in the code above with the URL to our SWF video on Mozqa.com -- it works.
FYI, in case I wasn't clear before, this is how YouTube does their embedding. Go to any video click the Share button then the Embed button.
Depends on: 705238
Attached patch patch v1.0 [backed-out] (obsolete) — Splinter Review
The test page still uses the old flash files. Bug 705238 has to land before this one.
Assignee: nobody → alex.lakatos
Status: NEW → ASSIGNED
Attachment #576891 - Flags: review?(anthony.s.hughes)
Attachment #576891 - Attachment description: patch v1.0 → patch v1.0 [checked-in]
Attachment #576891 - Flags: review?(anthony.s.hughes) → review+
Please verify with tomorrow's testrun.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This appears to be causing a crash in the testruns. See: http://mozmill-release.brasstacks.mozilla.com/#/endurance/report/45c0ad8f20b88e32d5d7aab6295c48bf http://mozmill-release.brasstacks.mozilla.com/#/endurance/report/45c0ad8f20b88e32d5d7aab6295bdf90 It would appear that memory is not being cleared between iterations as expected. Can we replicate this locally? We might need to back this out as it's preventing us from seeing results form other endurance tests.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yes, we should backout the patch for now. Since it has been landed on all branches, we have to take care of any of those. For the future I would really like to propose that we only land it on default and once it has been proven to work we backport it to other branches.
Status: REOPENED → ASSIGNED
(In reply to Henrik Skupin (:whimboo) [away 11/25 - 12/03] from comment #9) > Yes, we should backout the patch for now. Since it has been landed on all > branches, we have to take care of any of those. For the future I would > really like to propose that we only land it on default and once it has been > proven to work we backport it to other branches. I agree Henrik, and is something I was going to propose to the team. I was just waiting until you returned from vacation to send out.
Anthony, why this hasn't been backed out yesterday? Any disconnect should cause an immediate backout. Dave, can you please take care of? We need a clean testrun today. Thanks.
Backed out: http://hg.mozilla.org/qa/mozmill-tests/rev/026bab19d77a (default) http://hg.mozilla.org/qa/mozmill-tests/rev/e97be7416ca7 (mozilla-aurora) http://hg.mozilla.org/qa/mozmill-tests/rev/bc6e1c4e2bc8 (mozilla-beta) http://hg.mozilla.org/qa/mozmill-tests/rev/b8a8a35f3e9b (mozilla-release) Can we try to replicate this locally with different versions of Firefox as this may be a critical regression.
Attachment #576891 - Attachment description: patch v1.0 [checked-in] → patch v1.0 [backed-out]
I think this is likely caused by the same issue as bug 671476 comment 71. I'm noticing a degradation in performance over time (possibly GC related). Let's debug it on bug 671476 and see if the fix applies to all of these tests.
Depends on: 671476
I would propose to file a new bug for the investigation, just to limit the conversation over on bug 671476. Also we could move such a new bug into another component if it's really not our fault.
(In reply to Henrik Skupin (:whimboo) from comment #14) > I would propose to file a new bug for the investigation, just to limit the > conversation over on bug 671476. Also we could move such a new bug into > another component if it's really not our fault. We will make that call by discussing on bug 671476 to limit the discussion happening across several bugs.
Depends on: 708270
Dave, is that a test which would still be useful for us?
Assignee: alex.lakatos.dev → nobody
Status: ASSIGNED → NEW
Yes, I believe so.
Please at least update the license block in the patch and request review.
Attached patch patch v1.1 (obsolete) — Splinter Review
I have modified the patch to have the new license and also made changes: - added aModule parameter to setupModule - added tearDown because we might be failing at waitForPageLoad and not close the tabs before the end of the test - added manifest.ini inside the new folder - added the new manifest.ini to the endurance/manifest.ini Reports were done together with the new changes from bug 671476 since there were issues running both of them in a single testrun. Linux: http://mozmill-crowd.blargon7.com/#/endurance/report/8ec48e7ab0431a61b624e36d31ff4d2c Windows: http://mozmill-crowd.blargon7.com/#/endurance/report/c8094a822ef568b588c5eddaca00cf92 MAC: http://mozmill-crowd.blargon7.com/#/endurance/report/c8094a822ef568b588c5eddaca0fe07c NOTE: This patch was created above the one from bug 671476 since this bug is dependent on it. Also, both patches are modifying the manifest.ini from endurance. It takes about 2 hours for the endurance runs after adding these two tests
Assignee: nobody → dpetrovici
Attachment #576891 - Attachment is obsolete: true
Attachment #739081 - Flags: review?(andreea.matei)
Apart from both modifying the same manifest file, I don't see in interdependency here. Both bugs should have patches based on default, and whichever lands last will likely need an update to apply.
No longer depends on: 671476
Comment on attachment 739081 [details] [diff] [review] patch v1.1 Review of attachment 739081 [details] [diff] [review]: ----------------------------------------------------------------- Please don't based patches on top of other unlanded patches.
Attachment #739081 - Flags: review?(andreea.matei) → review-
Comment on attachment 739081 [details] [diff] [review] patch v1.1 >+const TEST_DOMAIN = "http://www.mozqa.com/"; >+const TEST_PAGE = TEST_DOMAIN + "data/firefox/plugins/flash/test_swf_iframes.html"; Please use test_swf_iframes_nosound.html
Attached patch patch v1.2 (obsolete) — Splinter Review
Attachment #739081 - Attachment is obsolete: true
Attachment #739596 - Flags: review?(andreea.matei)
Comment on attachment 739596 [details] [diff] [review] patch v1.2 Review of attachment 739596 [details] [diff] [review]: ----------------------------------------------------------------- ::: tests/endurance/testFlash_SWFVideoIframe/test1.js @@ +7,5 @@ > +var endurance = require("../../../lib/endurance"); > +var tabs = require("../../../lib/tabs"); > + > +const BASE_URL = "http://www.mozqa.com/"; > +const TEST_URL = BASE_URL + "data/firefox/plugins/flash/test_swf_iframes.html"; I think what was established in bug 827752 for the remote pages was to use TEST_URL and not separate the link in 2 constants. Also as Dave pointed, we should use test_swf_iframes_nosound.html @@ +14,5 @@ > + > +function setupModule(aModule) { > + aModule.controller = mozmill.getBrowserController(); > + > + aModule.enduranceManager = new endurance.EnduranceManager(controller); aModule.controller as parameter @@ +15,5 @@ > +function setupModule(aModule) { > + aModule.controller = mozmill.getBrowserController(); > + > + aModule.enduranceManager = new endurance.EnduranceManager(controller); > + aModule.tabBrowser = new tabs.tabBrowser(controller); Same here @@ +25,5 @@ > + if (aAddon.isActive && aAddon.type === "plugin" && aAddon.name === "Shockwave Flash") > + return true; > + }); > + > + if (isFlashActive[0] !== true) { We could use !isFlashActive[0] here. @@ +26,5 @@ > + return true; > + }); > + > + if (isFlashActive[0] !== true) { > + testFlashURL.__force_skip__ = "No enabled Flash plugin detected"; This should be testFlashIframe() and please skip teardownModule() as well. @@ +51,5 @@ > + controller.open(TEST_URL); > + controller.waitForPageLoad(TIMEOUT_PAGE); > + enduranceManager.addCheckpoint("Web page has been loaded"); > + }); > + // Close all tabs We can remove this comment and leave a blank line, as it is cleared from the method's name what it will do.
Attachment #739596 - Flags: review?(andreea.matei) → review-
Status: NEW → ASSIGNED
Attached patch patch v1.4Splinter Review
Attachment #740683 - Attachment is obsolete: true
Attachment #740683 - Flags: review?(andreea.matei)
Attachment #742991 - Flags: review?(andreea.matei)
Comment on attachment 742991 [details] [diff] [review] patch v1.4 Review of attachment 742991 [details] [diff] [review]: ----------------------------------------------------------------- Landed as: http://hg.mozilla.org/qa/mozmill-tests/rev/23fbcafd2b77 (default) Dave, can we close this now without backporting?
Attachment #742991 - Flags: review?(andreea.matei) → review+
As mentioned in yesterday's meeting, we do backport new endurance tests.
Attachment #746868 - Flags: review?(andreea.matei)
Attachment #746868 - Flags: review?(andreea.matei) → review+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago12 years ago
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: