Merge lp:~rpadovani/webbrowser-app/newTabRefactoring into lp:webbrowser-app
| Status: | Merged |
|---|---|
| Approved by: | Olivier Tilloy on 2015-05-25 |
| Approved revision: | 901 |
| Merged at revision: | 1038 |
| Proposed branch: | lp:~rpadovani/webbrowser-app/newTabRefactoring |
| Merge into: | lp:webbrowser-app |
| Diff against target: |
773 lines (+351/-279) 6 files modified
src/app/webbrowser/Browser.qml (+59/-59) src/app/webbrowser/NewTabView.qml (+200/-126) src/app/webbrowser/UrlsList.qml (+72/-93) src/app/webbrowser/bookmarks-model.cpp (+3/-1) src/app/webbrowser/bookmarks-model.h (+2/-0) tests/unittests/bookmarks-model/tst_BookmarksModelTests.cpp (+15/-0) |
| To merge this branch: | bzr merge lp:~rpadovani/webbrowser-app/newTabRefactoring |
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-05-25 | |
| Olivier Tilloy | 2015-01-24 | Approve on 2015-05-25 | |
|
Review via email:
|
|||
Commit Message
New tab view refactoring.
Description of the Change
Improved the new tab accordingly to UX
# Fixed bugs
- the "see more" / "see less" actions for bookmarks should be in the section header
- Bookmarks section header in new tab view not updated when a bookmark is added/removed
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:878
http://
Executed test runs:
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
FAILURE: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
That looks closer to the visual spec, but needs tweaking still:
- the More/Less button should have a strokeColor of "#5d5d5d"
- it should be taller
- there should be an orange star to the left of the "bookmarks" section header
- when expanding the bookmarks section, the "popular sites" one should be hidden (just like the current implementation does, which your patch seems to change)
| Riccardo Padovani (rpadovani) wrote : | # |
> That looks closer to the visual spec, but needs tweaking still:
> - the More/Less button should have a strokeColor of "#5d5d5d"
> - it should be taller
Fixed
> - there should be an orange star to the left of the "bookmarks" section
> header
Added, but I had to rewrite all the header, let me know if it's still good
> - when expanding the bookmarks section, the "popular sites" one should be
> hidden (just like the current implementation does, which your patch seems to
> change)
I thought it was because when you click on "more" in the old implementation it shows all the bookmarks, and now it's 5 by 5. Anyway, I've restored it!
Thanks :-)
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:879
http://
Executed test runs:
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
FAILURE: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
| Francis Ginther (fginther) wrote : | # |
The jenkins node for the i386 build failed, I've restarted a new ci run.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:879
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:880
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:880
http://
Executed test runs:
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
This looks better, however I’m seeing some glitches, see the screenshots at http://
- capture.png shows how the new page looks like when there are no bookmarks
- capture2.png shows how it looks like after adding a bookmark if it was initially created with no bookmarks
| Riccardo Padovani (rpadovani) wrote : | # |
As note, this could be related: https:/
| Riccardo Padovani (rpadovani) wrote : | # |
Ok, now should be ok.
Let me do a summary on this branch and on the new tab view, maybe there are better solutions of the one I thought.
So, designers want the behavior of the new tav view is like a listview with two sections, bookmarks and topsites.
The problem we have the model of bookmarks and of topsites are two different models.
A possible solution is to create a new model that is a merge of the others two, but could be have some problems, so I preferred to avoid this.
The solution already implemnented is to create a lisview with two delegate, a bookmark and a topsite.
Every delegate has another listview (or repeater) inside, with the related model.
The solution works well, but miss a the adding/removing of the section header when the last element is added/removed (as bug #1389605 reports).
My first thought was to use 'visible' element in the section header, but for some reason it doesn't work (at least on vivid). You can try just adding 'visible: false' in the section header.
So I choose to set height of the section header to 0 when there is nothing in the delegate, but I hit the upstream bug I reported in the comment above.
In the last commit I changed the approach: I add/remove section in the main listview when there aren't elements anymore.
I think this worsk well, but it doesn't scale well (if in a future we want to add a third section it's quite a mess) and the code is a bit ugly, but I haven't figured any better solution.
What do you think?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:881
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
Mmm… that does look ugly indeed, and is not scalable, but I understand the problem as you clearly expressed it.
In any case with this approach, there’s one thing that needs fixing:
} else if (numberOfBookmarks == 1 &&
[…]
} else if (numberOfTopSites == 1 &&
you need to check for numberOf… > 0, as we cannot assume that only one bookmark or one topsite was added
Another approach we could take is to not use section delegates, i.e. implement the entire new tab view as a column inside a flickable. That would remove much of the complexity of the code, I think.
| Riccardo Padovani (rpadovani) wrote : | # |
We discussed about this on IRC, but I left a comment here as future reference.
I found a couple of bugs with limitedlistview:
- it doesn't emit a signal when the number of bookmarks change so if you have 5 bookmarks, open a new page, bookmark it, and then return to the new tab view, there isn't the button 'show more'. But there is if you open a *new* new tab
- If I place the limitedlistview in a column, how we discussed, there is a strange bug when you remove an element: let's say the model has 6 elements and the limit is 5: column contentHeight is limitedlistview
| Riccardo Padovani (rpadovani) wrote : | # |
Okay, I changed approach, what do you think? It doesn't hide anymore sections header. I think I removed all unused code, but could be there is some useless code.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:883
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Riccardo Padovani (rpadovani) wrote : | # |
Actually, I also found a workaround for the LimitProxyModel bug (it doesn't emit the signal when a delegate is removed), so now it should works well in any case (add more than 5 elements, the show more button appears, fix bug #1442190).
Now we can do whatever we want with sections, we can also hide headers when we want.
And I think code is cleaner.
A thing I can do is adding a count property to BookmarksModel class to avoid to use LimitProxyModel to count number of object (but we still need it for the top sites section).
I propose an implementation I like, but we can discuss it now there isn't any of the bug I reported in previous comments.
What do you think?
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:884
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
Let’s put this on hold for a week or two: Arthur is currently working on updating the design of the top sites section, and that will likely conflict with your changes (sorry I didn’t see that coming). I think most (if not all) of your changes will still apply, but there’s likely going to be a few conflicts to resolve.
I’d be curious to see if your changes fix bug #1444023 (which I just reported), by the way.
| Riccardo Padovani (rpadovani) wrote : | # |
> Let’s put this on hold for a week or two: Arthur is currently working on
> updating the design of the top sites section, and that will likely conflict
> with your changes (sorry I didn’t see that coming). I think most (if not all)
> of your changes will still apply, but there’s likely going to be a few
> conflicts to resolve.
No problem at all, I'll wait for the update :-)
> I’d be curious to see if your changes fix bug #1444023 (which I just
> reported), by the way.
Mhhh maybe, I need to test that
| Riccardo Padovani (rpadovani) wrote : | # |
Ok, I updated the MR, now is definitely cleaner and seems to solve in an elegant way all our bugs :-)
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:887
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
I’m seeing a number of minor discrepancies with the visual spec (https:/
- the star icon for the bookmarks section header is too big
- the font size for the section headers should be small
- the spacing above and below the section headers should be increased (there should be 1GU above and 1GU below the More/Less button)
- the color of the horizontal line is not correct
- there should be much more spacing between the bottom of the bookmarks section and the top of the top sites section
Also, a functional issue:
- when I press the More button to expand the bookmarks section, I can scroll the top of the list view out of sight, even though the listview doesn’t completely fill the screen
| Olivier Tilloy (osomon) wrote : | # |
424 + Component.
425 + if (model.hidden !== undefined && model.hidden) {
426 + height = 0;
427 + limit++;
428 + }
429 + }
The above is not correct. Use the TopSitesModel that filters out hidden entries instead.
| Riccardo Padovani (rpadovani) wrote : | # |
Hi Olivier,
thanks for your review!
I addressed all your comments about UI.
But I've troubles with the TopSitesModel component - I'm sure I'm missing something very easy, but I'm not able to figure what. At the moment no sites are displayed in the top sites area, but no error are printed on the console.
Could you take a look, please?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:888
http://
Executed test runs:
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
This is getting there, nice job! And it now fixes 5 bugs (just added one to the list), you’re going to set a new record here :)
A few comments to address still:
If I have a number of bookmarks (more than 5), then open a new tab and start removing all bookmarks by swiping them to the right and confirming, they are correctly removed (and following bookmarks in the list show up), but the height of the bookmarks section is not updated, it doesn’t shrink when the total number of bookmarks gets < 5. Eventually, when only one bookmark is left, there is a big, almost empty bookmarks section, which looks akward. If I then open another new tab, the section’s height is correct.
There should be some spacing above the message that says that the user hasn’t visited any sites yet, it’s currently stuck to the section separator, which looks ugly. And the text color probably shouldn’t be plain black.
numberOfBookmarks and numberOfTopSites should check that bookmarksModel and historyModel are not null before trying to read their 'count' properties. This is because those models are instantiated asynchronously at startup. If a blank tab is restored at startup and for some reason the models take a long time to load, you will see (harmless) warnings in the console. Those are easy enough to fix that it’s worth doing it.
There should be some spacing between the bottom of the top sites list and the bottom of the window, to account for the bottom edge hint on mobile (I guess it’s ok to have that spacing unconditionally, even on desktop where it’s not strictly needed).
In the UrlList for top sites, why do you increase the limit in the onUrlRemoved handler?
Can you update the unit tests for the bookmarks model to check that the rowCountChanged signal is correctly emitted when expected, and that the value of the count is always as expected?
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:889
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:892
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Riccardo Padovani (rpadovani) wrote : | # |
> If I have a number of bookmarks (more than 5), then open a new tab and start
> removing all bookmarks by swiping them to the right and confirming, they are
> correctly removed (and following bookmarks in the list show up), but the
> height of the bookmarks section is not updated, it doesn’t shrink when the
> total number of bookmarks gets < 5. Eventually, when only one bookmark is
> left, there is a big, almost empty bookmarks section, which looks akward. If I
> then open another new tab, the section’s height is correct.
Actually, I wasn't able to reproduce this. Are you on vivid?
But I reproduced a similar issue: if I've 2 new tab view open, and I remove bookmarks in the 2nd one, the height in the 1st isn't updated. I fixed that, so I hope it fixes also the one you found.
Also, I found a similar issue with 'See more' - expand in one tab, remove bookmarks in the other one, go back - but I think I fixed also this one
> There should be some spacing above the message that says that the user hasn’t
> visited any sites yet, it’s currently stuck to the section separator, which
> looks ugly. And the text color probably shouldn’t be plain black.
Done, and now the text it's of the same color of 'See more' button
> numberOfBookmarks and numberOfTopSites should check that bookmarksModel and
> historyModel are not null before trying to read their 'count' properties. This
> is because those models are instantiated asynchronously at startup. If a blank
> tab is restored at startup and for some reason the models take a long time to
> load, you will see (harmless) warnings in the console. Those are easy enough
> to fix that it’s worth doing it.
Done
> There should be some spacing between the bottom of the top sites list and the
> bottom of the window, to account for the bottom edge hint on mobile (I guess
> it’s ok to have that spacing unconditionally, even on desktop where it’s not
> strictly needed).
Are you sure? Having a gray line at bottom is ugly, and the effect is very strange.
Take a look to Dekko or Reminders, they don't have any space at bottom, and looks good anyway
> In the UrlList for top sites, why do you increase the limit in the
> onUrlRemoved handler?
Legacy code from the first implementation, thanks, removed
> Can you update the unit tests for the bookmarks model to check that the
> rowCountChanged signal is correctly emitted when expected, and that the value
> of the count is always as expected?
Done
| Olivier Tilloy (osomon) wrote : | # |
> I fixed that, so I hope it fixes also the one you found.
It seems to fix the issue I was seeing indeed.
> Are you sure? Having a gray line at bottom is ugly, and the effect
> is very strange.
It shouldn’t be a gray line, just some additional empty space, IMHO. Anyway, I’m fine with keeping it like that for now, changing that in the future is easy if we want to.
Some additional remarks:
The item that contains the "You haven't visited any site yet" text doesn’t need to be rectangle, it could simply be a plain Item. This will avoid an ugly white background. Actually it doesn’t even need a container, the Text could be made larger, and its text vertically centered.
The (bookmarksModel
In onNumberOfBookm
Also, in the same if() block, you don’t need to check the value of seeMoreBookmark
Please do not add semi-colons at the end of lines for pure QML code (javascript is OK, although throughout the code base we tend not to use them).
Finally, one suggestion for performance optimization: I don’t know why we have one new tab view per webview in the first place, but it seems to me that one instance for all webviews would be enough. We would avoid lots of potential issues with updating one view and not the others, and of course it would perform better as we would instantiate fewer objects. Do you think you can do that change? In Browser.qml, around line 176, we would need an additional Loader, similar to the two loaders above (one is for the ErrorSheet and the other one for the InvalidCertific
| Riccardo Padovani (rpadovani) wrote : | # |
> > Are you sure? Having a gray line at bottom is ugly, and the effect
> > is very strange.
>
> It shouldn’t be a gray line, just some additional empty space, IMHO. Anyway,
> I’m fine with keeping it like that for now, changing that in the future is
> easy if we want to.
Okay, so I leave it as it is now
> Some additional remarks:
>
> The item that contains the "You haven't visited any site yet" text doesn’t
> need to be rectangle, it could simply be a plain Item. This will avoid an ugly
> white background. Actually it doesn’t even need a container, the Text could be
> made larger, and its text vertically centered.
Yap, right
> The (bookmarksModel
> undefined) checks are unnecessary: as long as bookmarksModel and historyModel
> are not null, it is safe to expect them to have a count property. If they
> don’t then something much bigger is broken anyway.
Okay
> In onNumberOfBookm
> than for equality. If for some reason two bookmarks are removed in a batch,
> that number might go from 5 to 3 without stepping at 4, and the condition
> wouldn’t be verified.
Right, it makes sense, thanks!
> Also, in the same if() block, you don’t need to check the value of
> seeMoreBookmark
> already false, nothing will happen.
Oh, right, thanks
> Please do not add semi-colons at the end of lines for pure QML code
> (javascript is OK, although throughout the code base we tend not to use them).
Okay, I'll try to avoid them
> Finally, one suggestion for performance optimization: I don’t know why we have
> one new tab view per webview in the first place, but it seems to me that one
> instance for all webviews would be enough. We would avoid lots of potential
> issues with updating one view and not the others, and of course it would
> perform better as we would instantiate fewer objects. Do you think you can do
> that change? In Browser.qml, around line 176, we would need an additional
> Loader, similar to the two loaders above (one is for the ErrorSheet and the
> other one for the InvalidCertific
Done, hope it's ok
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:893
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
In NewTabView.qml, please s/Text/Label/, to ensure consistent theming.
newTabViewLoader is well placed, but there are a few issues with it:
- it shouldn’t fill the parent, its anchors should be the same as the two other Loaders above it
- please set its 'asynchronous' property to true, to ensure it doesn’t block rendering at startup
- the NewTabView component should be loaded only when needed, not always (like it is now)
| Riccardo Padovani (rpadovani) wrote : | # |
Fixed all, I think
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:894
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
When launching the app, previously open tabs are restored (default behaviour), and the webview for the current tab loads, but for a brief moment I can see the new tab view displayed. It shouldn’t be loaded at all in this case.
Conversely, when I open a new tab, the new tab view is not displayed.
Also, I’m seeing the following warning in the console at startup:
QQmlExpression: Expression file://
WebViewImpl
To address those issues, I think you need to do the following:
- sourceComponent should not be set (no property binding)
- have a Connections object that monitors when currentWebview changes and that does what was done prior to your changes in the Loader’s Component.
One thing we’ll need to verify is that when switching from one empty tab to another empty tab, the new tab view isn’t deleted and re-created. We could easily write an autopilot test for that, but given that there are zero autopilot tests for this feature so far, let’s add some in a separate MR (I’ll do it).
Another minor remark: I think "anchors.fill: parent" inside the NewTabView instance is unneeded, since by default a component will be anchored to fill its parent loader.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:895
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
I’m still seeing the new tab view being briefly instantiated and destroyed right away at startup, when restoring a tab that isn’t empty. This needs fixing, as it adds unnecessarily to the startup time (and the view can actually be seen for a split second, which is confusing).
Otherwise I verified that when switching from one new tab to another new tab the view isn’t destroyed and re-created, that’s good.
| Olivier Tilloy (osomon) wrote : | # |
After some deep investigation, I finally nailed where the issue is: the problem is that oxide’s WebView.
Also one note that will simplify the code: instead of setting sourceComponent conditionally on the Loader, we can set it once, and then toggle the 'active' property of the loader.
I produced a patch that does those two things and should apply cleanly on top of your branch: http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:896
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
That looks great now, thanks!
Note: there will be conflicts in Browser.qml and NewTabView.qml when merging into trunk after https:/
| Olivier Tilloy (osomon) wrote : | # |
The private browsing branch landed in trunk, and this MR now conflicts.
| Riccardo Padovani (rpadovani) wrote : | # |
Fixed (I hope, I don't have oxide updated on this pc and I'm not able to test it)
| Olivier Tilloy (osomon) wrote : | # |
8 -import Ubuntu.
Please do not remove that line, it is needed.
44 + sourceComponent: webviewimpl.
This should be browser.incognito, not webviewimpl.
151 - function resetFocus() {
This function is still being used, it shouldn’t be removed.
168 - var tab = tabComponent.
169 + var tab = tabComponent.
This change should be reverted.
177 - for (var i = 0; i < publicTabsModel
178 - var tab = publicTabsModel
179 + for (var i = 0; i < tabsModel.count; ++i) {
180 + var tab = tabsModel.get(i)
This change should be reverted.
- 900. By Riccardo Padovani on 2015-05-25
-
Fix wronge merge request
| Riccardo Padovani (rpadovani) wrote : | # |
Sorry for the wrong merge, I should have fixed all now
| Olivier Tilloy (osomon) wrote : | # |
Thanks, that’s better! Can you remove the anchors in the NewPrivateTabView instance in Browser.qml? They are not needed since the parent loader already defines its anchors (the loaded item will fill its parent loader by default).
- 901. By Riccardo Padovani on 2015-05-25
-
Remove useless anchors
| Riccardo Padovani (rpadovani) wrote : | # |
Done :-)
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:901
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://

FAILED: Continuous integration, rev:876 jenkins. qa.ubuntu. com/job/ webbrowser- app-ci/ 1388/ jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- vivid-touch/ 970 jenkins. qa.ubuntu. com/job/ generic- mediumtests- vivid/445 jenkins. qa.ubuntu. com/job/ webbrowser- app-vivid- amd64-ci/ 146 jenkins. qa.ubuntu. com/job/ webbrowser- app-vivid- armhf-ci/ 146 jenkins. qa.ubuntu. com/job/ webbrowser- app-vivid- armhf-ci/ 146/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ webbrowser- app-vivid- i386-ci/ 146 jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- runner- vivid-mako/ 859 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-armhf/ 968 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-armhf/ 968/artifact/ work/output/ *zip*/output. zip s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 17413 jenkins. qa.ubuntu. com/job/ autopilot- testrunner- otto-vivid/ 365 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-amd64/ 537 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-amd64/ 537/artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
UNSTABLE: http://
UNSTABLE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
UNSTABLE: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/webbrowser- app-ci/ 1388/rebuild
http://