Closed Bug 790538 Opened 12 years ago Closed 5 years ago

Enhance update tests to check for the 'what's new page' when `actions='silent'` given in update snippet

Categories

(Testing :: Firefox UI Tests, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

()

Details

As given on bug 789422 we would have to add another check to our update tests which ensure that the `what's new page` is only shown when `actions` have not been set to silent. See the moztrap case for details: https://moztrap.mozilla.org/manage/case/1371/ This has to be implemented for both the direct and fallback update paths. To get started please read: https://developer.mozilla.org/en/Mozmill_Tests Further you will have to do the following steps: 1. Get the mozmill-automation scripts: http://hg.mozilla.org/qa/mozmill-automation/ 2. Run the update tests via ./testrun_update.py (--help gives you details)
Priority: -- → P2
Henrik, I'd be happy to make an attempt at this in my limited spare time. Since we'll need to check this manually for releases in the meantime, it's very important to me to get this fixed ASAP. To start, I'm wondering how we can retrieve the actions parameter from the update.xml file?
Should be part of nsIUpdate: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsIUpdateService.idl#91 But check back with Rob or have a look at the patch how the value gets evaluated. If you dont' find the time we can make it a priority next week. It's already a P2 bug.
We will take this as a task for SV this week.
Whiteboard: [mentor=whimboo][lang=js] → s=q3 u=enhance c=software_update p=1
We have to drop it for this week regarding bug 790191 we have to fix instead.
Whiteboard: s=q3 u=enhance c=software_update p=1
Whiteboard: s=q3 u=enhance c=software_update p=1
Seems like we could just grab the update.xml file based on the app.update.url pref which you already have assigned to the PREF_APP_UPDATE_URL constant in the software-update.js library. Question is, do we have a library to parse out the actions= parameter from the xml file?
No, that's not what I would propose to do. The information should be available in one of the update interfaces. Anthony, it would be great if you can give us two AUS URLs, one which points to action='silent' and the other which is a default update.
(In reply to Henrik Skupin (:whimboo) from comment #6) > No, that's not what I would propose to do. The information should be > available in one of the update interfaces. > > Anthony, it would be great if you can give us two AUS URLs, one which points > to action='silent' and the other which is a default update. Well, actions="silent" is supposed to be the default, in other words the default is to never show a What's New page. There are some circumstances where we will want to show a What's New page and in those cases, actions="silent" is removed from the snippet. Here is an example AUS URL with the parameter: https://aus3.mozilla.org/update/3/Firefox/15.0/20120824154833/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/release/Darwin%2010.8.0/default/default/update.xml
Whiteboard: s=q3 u=enhance c=software_update p=1 → s=121015 u=enhance c=software_update p=1
Assignee: nobody → alex.lakatos
Status: NEW → ASSIGNED
I can't see a way to get/set the actions value from the interface. I found that the existing tests do this by writing out an XML file: http://mxr.mozilla.org/mozilla-central/source/browser/components/test/browser_bug538331.js#314 I believe Henrik is referring to Rob Strong in comment 2. CC'ing him in case he has any suggestions.
(In reply to Dave Hunt (:davehunt) from comment #8) > I can't see a way to get/set the actions value from the interface. I found > that the existing tests do this by writing out an XML file: > http://mxr.mozilla.org/mozilla-central/source/browser/components/test/ > browser_bug538331.js#314 > > I believe Henrik is referring to Rob Strong in comment 2. CC'ing him in case > he has any suggestions. Correct. Lets use the need-info flag to get the feedback from Rob.
Flags: needinfo?(robert.bugzilla)
(In reply to Dave Hunt (:davehunt) from comment #8) > I can't see a way to get/set the actions value from the interface. I found > that the existing tests do this by writing out an XML file: > http://mxr.mozilla.org/mozilla-central/source/browser/components/test/ > browser_bug538331.js#314 There is no need for the update service interface to provide methods to consumers for creating the xml so you will need to either create the xml yourself or have a test xml served to the client with the appropriate values. Both of these methods are used by the existing tests.
Flags: needinfo?(robert.bugzilla)
(In reply to Robert Strong [:rstrong] (vac 10/26-11/4) (do not email) from comment #10) > There is no need for the update service interface to provide methods to > consumers for creating the xml so you will need to either create the xml > yourself or have a test xml served to the client with the appropriate > values. Both of these methods are used by the existing tests. Rob, with the Mozmill tests we do not want to create the XML by ourselves. As you know we are running live update tests, so we will have to check what happens after an update based on the original update snippet served by the server. Does it mean that we have to simply parse the XML content of the update snippet? If that's the case I'm fine with it.
(In reply to Henrik Skupin (:whimboo) from comment #11) > (In reply to Robert Strong [:rstrong] (vac 10/26-11/4) (do not email) from > comment #10) > > There is no need for the update service interface to provide methods to > > consumers for creating the xml so you will need to either create the xml > > yourself or have a test xml served to the client with the appropriate > > values. Both of these methods are used by the existing tests. > > Rob, with the Mozmill tests we do not want to create the XML by ourselves. > As you know we are running live update tests, so we will have to check what > happens after an update based on the original update snippet served by the > server. Does it mean that we have to simply parse the XML content of the > update snippet? If that's the case I'm fine with it. Henrik, I was replying specifically to the question asked in comment #8 about being able to "get/set the actions from the interface". (In reply to Robert Strong [:rstrong] (vac 10/26-11/4) (do not email) from comment #10) > (In reply to Dave Hunt (:davehunt) from comment #8) > > I can't see a way to get/set the actions value from the interface. I found > > that the existing tests do this by writing out an XML file: > > http://mxr.mozilla.org/mozilla-central/source/browser/components/test/ > > browser_bug538331.js#314 To read the Firefox specific values from the update.xml about the what's new page you should be able to use the following Firefox specific code. http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#141
(In reply to Robert Strong [:rstrong] (vac 10/26-11/4) (do not email) from > To read the Firefox specific values from the update.xml about the what's new > page you should be able to use the following Firefox specific code. > http://mxr.mozilla.org/mozilla-central/source/browser/components/ > nsBrowserContentHandler.js#141 That's all what we need here. Thank you a lot! Alex, can you please get started to implement the enhancements?
(In reply to Henrik Skupin (:whimboo) from comment #13) > > That's all what we need here. Thank you a lot! Alex, can you please get > started to implement the enhancements? Sure.
Assignee: alex.lakatos.dev → andrei.eftimie
Assignee: andrei.eftimie → nobody
Status: ASSIGNED → NEW
Whiteboard: s=121015 u=enhance c=software_update p=1 → [mentor=whimboo][lang=js]
Mentor: hskupin
Whiteboard: [mentor=whimboo][lang=js] → [lang=js]
Component: Mozmill Tests → Firefox UI Tests
Depends on: 1129843
Mentor: hskupin
Whiteboard: [lang=js]
Product: Mozilla QA → Testing

Update tests are dead and will be removed by bug 1573406.

Status: NEW → RESOLVED
Closed: 5 years ago
QA Contact: hskupin
Resolution: --- → WONTFIX
See Also: → 1573406
You need to log in before you can comment on or make changes to this bug.