[BUG-202607] Object Media / MOAP Does not update reliably

[sl-service-account]

I was working on a previously working, stable product which switches between youtube videos and a data URI page as a method of playing and pausing videos. Recently, the MOAP browser has become increasingly unstable. This appears to only be a problem with URL changes dictated by a script, but I have not done extensive testing with manual address changes.

Steps to Reproduce

See the script in Other Information. Bug #1 is consistently reproducible via that script.

Actual Behavior

There's two similar, possibly related, but distinct bugs.

1. Sometimes when using llSetMediaParams/PRIM_MEDIA_CURRENT_URL to change the current browser url, the page won't visibly change. Any playing video appears and sounds to have stopped playing, and the displayed page is not able to be interacted with. It appears that CEF has changed and loaded the page behind the scenes, but the SL Client displays a frozen image of the previous page. This persists until another page change is sent. See below for a script that reproduces this behavior reliably. It appears to involve sending a URL change and a resolution change at the same time.

2. The displayed page won't change after the llSetMediaParams/PRIM_MEDIA_CURRENT_URL function is used to change the URL to another page. Any playing video continues to play in the browser, and the page remains interactive. The browser will not respond to any further URL change requests from the server until the media "Stop All" and "Start All" buttons are used to reset it.

Expected Behavior

MOAP URL changes should be reliable, if not timely. Without the URL updates pushing to the MOAP browser reliably, I can't be certain that all users looking at the prim see the same thing, and this seriously affects the perceived reliability of my scripting work.

Other information

This bug affects a product I sell. https://marketplace.secondlife.com/p/MD-Sync-TV/6983615

I would be happy to provide any additional information, including more detail on the testing I've performed with other users, demonstrating the problems in person, making videos, and provide samples of my product in the interest of fixing this bug. It has the potential to do a lot of damage to my sales.

The script below, dropped into a cube, will reproduce one of the types of error I have been encountering 100% of the time on both first party and third party viewers. It's a distilled block of code that duplicates part of the functionality of that product. I've simplified it as far as possible to make it easier to track down the bugs.

Click any side except the media face (face 0) to cycle between pages. The displayed page quickly goes out of sync from the URL sent from the sim. Interestingly, the page seems to load behind the scenes, and can be interacted with. Eg: The displayed page is stuck on youtube, but it's possible to drag and select the number on the unseen page, and successfully copy and paste it via ctrl-c and ctrl-v.

I will reiterate, this only duplicates the first of the two issues I have mentioned. The other bug, where the browser doesn't update the page at all (videos continue to play, and the page remains interactive,) is more elusive and difficult to tack down and reproduce reliably, but I still encounter it quite regularly.

integer page = 0;

default
{
    state_entry()
    {
        llSetText("Click me on any side but the top. (Face 0)", <1.0, 1.0, 1.0>, 1.0);
    }

    touch_start(integer total_number)
    {
        //llSetText("Number that should be displayed: " + (string)page, <1.0, 1.0, 1.0>, 1.0);

        if ((page % 2) == 0)
        {
            llSetText("The number " + (string)page + " should be showing.", <1.0, 1.0, 1.0>, 1.0);
            llSetPrimitiveParams( [PRIM_TEXTURE, 0] +
                          llListReplaceList( llGetPrimitiveParams( [PRIM_TEXTURE, 0] ),
                                             [<0.625, 0.70313, 0>, <-0.18751, -0.141844, 0.0>],
                                             1,
                                             2 ) );
            llSetPrimMediaParams(0, [PRIM_MEDIA_WIDTH_PIXELS, 1280, PRIM_MEDIA_HEIGHT_PIXELS, 720, PRIM_MEDIA_CURRENT_URL, "data:text/html;charset=utf-8,%3Chtml%3E%3Chead%3E%3Cstyle%20type%3D%22text%2Fcss%22%3Ebody%20%7Bdisplay%3A%20flex%3B%20justify-content%3A%20center%3B%20align-items%3A%20center%3B%20height%3A%20100%25%3Boverflow%3A%20hidden%3Bfont-size%3A%20400px%7D%3C%2Fstyle%3E%3C%2Fhead%3E%3Cbody%3E" + (string)page + "%3C%2Fbody%3E%3C%2Fhtml%3E"]);
        }

        if ((page % 2) == 1)
        {
            llSetText("Youtube should be showing.", <1.0, 1.0, 1.0>, 1.0);
            llSetPrimitiveParams( [PRIM_TEXTURE, 0] +
                          llListReplaceList( llGetPrimitiveParams( [PRIM_TEXTURE, 0] ),
                                             [<0.4163, 0.4682, 0.0> , <-0.21751, 0.086, 0.0>],
                                             1,
                                             2 ) );
            llSetPrimMediaParams( 0, [PRIM_MEDIA_WIDTH_PIXELS, 1600, PRIM_MEDIA_HEIGHT_PIXELS, 900, PRIM_MEDIA_CURRENT_URL, "https://www.youtube.com/watch?v=ggUt6kusHj8"]);
        }
        page++;

    }

}

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-202607 | | Summary | Object Media / MOAP Does not update reliably | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Maloo Eliot (maloo.eliot) | | Created at | 2017-11-18T05:50:15Z | | Updated at | 2020-04-30T14:07:36Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2017-11-18T23:24:24.860-0600', "Is there anything you'd like to add?": 'This bug affects a product I sell.\r\nhttps://marketplace.secondlife.com/p/MD-Sync-TV/6983615\r\n\r\nI would be happy to provide any additional information, including more detail on the testing I\'ve performed with other users, demonstrating the problems in person, making videos, and provide samples of my product in the interest of fixing this bug. It has the potential to do a lot of damage to my sales.\r\n\r\n\r\nThe script below, dropped into a cube, will reproduce one of the types of error I have been encountering 100% of the time on both first party and third party viewers. It\'s a distilled block of code that duplicates part of the functionality of that product. I\'ve simplified it as far as possible to make it easier to track down the bugs.\r\n\r\n\r\n\r\n{code:lsl}\r\ninteger page = 0;\r\n\r\n\r\ndefault\r\n{\r\n state_entry()\r\n {\r\n llSetText("Click me on any side but the top. (Face 0)", <1.0, 1.0, 1.0>, 1.0);\r\n }\r\n\r\n\r\n touch_start(integer total_number)\r\n {\r\n //llSetText("Number that should be displayed: " + (string)page, <1.0, 1.0, 1.0>, 1.0);\r\n \r\n if ((page % 2) == 0)\r\n {\r\n llSetText("The number " + (string)page + " should be showing.", <1.0, 1.0, 1.0>, 1.0);\r\n llSetPrimitiveParams( [PRIM_TEXTURE, 0] +\r\n llListReplaceList( llGetPrimitiveParams( [PRIM_TEXTURE, 0] ),\r\n [<0.625, 0.70313, 0>, <-0.18751, -0.141844, 0.0>],\r\n 1,\r\n 2 ) );\r\n llSetPrimMediaParams(0, [PRIM_MEDIA_WIDTH_PIXELS, 1280, PRIM_MEDIA_HEIGHT_PIXELS, 720, PRIM_MEDIA_CURRENT_URL, "data:text/html;charset=utf-8,%3Chtml%3E%3Chead%3E%3Cstyle%20type%3D%22text%2Fcss%22%3Ebody%20%7Bdisplay%3A%20flex%3B%20justify-content%3A%20center%3B%20align-items%3A%20center%3B%20height%3A%20100%25%3Boverflow%3A%20hidden%3Bfont-size%3A%20400px%7D%3C%2Fstyle%3E%3C%2Fhead%3E%3Cbody%3E" + (string)page + "%3C%2Fbody%3E%3C%2Fhtml%3E"]);\r\n }\r\n \r\n if ((page % 2) == 1)\r\n {\r\n llSetText("Youtube should be showing.", <1.0, 1.0, 1.0>, 1.0);\r\n llSetPrimitiveParams( [PRIM_TEXTURE, 0] +\r\n llListReplaceList( llGetPrimitiveParams( [PRIM_TEXTURE, 0] ),\r\n [<0.4163, 0.4682, 0.0> , <-0.21751, 0.086, 0.0>],\r\n 1,\r\n 2 ) );\r\n llSetPrimMediaParams( 0, [PRIM_MEDIA_WIDTH_PIXELS, 1600, PRIM_MEDIA_HEIGHT_PIXELS, 900, PRIM_MEDIA_CURRENT_URL, "https://www.youtube.com/watch?v=ggUt6kusHj8"]);\r\n }\r\n page++;\r\n \r\n \r\n \r\n }\r\n\r\n}\r\n{code}', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Recently, the MOAP browser has become increasingly unstable. It will sometimes freeze and fail to update until the media "Stop All" and "Start All" buttons are used to reset it. This appears to only be a problem with URL changes dictated by a script.', 'What were you doing when it happened?': "I was working on a previously working, stable product which switches between youtube videos and a data URI page as a method of playing and pausing videos. Increasingly, I've been noticing strange behaviors where sometimes the page won't visibly change, but the video appears and sounds to have stopped playing. Or, on other occasions, the video won't stop playing after the llSetMediaParams/PRIM_MEDIA_CURRENT_URL function is used to change the URL to another page.", 'What were you expecting to happen instead?': "MOAP URL changes should be reliable, if not timely. Without the URL updates pushing to the MOAP browser reliably, I can't be certain that all users looking at the prim see the same thing, and this seriously affects the perceived reliability of my scripting work.", } ```

[sl-service-account]

Whirly Fizzle commented at 2017-11-19T05:24:25Z

This bug isn't specific to the Alex Ivy builds. Also reproduced on default release: Second Life 5.0.8.329115 (Second Life Release) & Firestorm 5.0.7.

Bug does not reproduce on older viewers using Webkit (Qt Webkit Version: 4.7.1). eg) http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.28.300847 Appears to be a problem with CEF.

[sl-service-account]

Maloo Eliot commented at 2017-11-19T07:42:36Z, updated at 2017-11-19T23:27:47Z

The first problem may have existed since the change to CEF, as I didn't run into it until I started using code that set the resolution and changed the URL with the same llSetPrimMediaParams call.

The second problem mentioned did not start with the change to CEF, and started showing up in builds sometime in the last several months. I can't pinpoint the date, but it was not an issue with CEF previously.

[sl-service-account]

Maloo Eliot commented at 2017-11-19T23:45:08Z

(I have updated the description based on further testing, and to clarify the nature of the issues further)