Mixing
UITableView.reload leaves old cells in TableView but hidden
I have a UITableView used to show search results. As I type, I’m calling Tableview.reloadData(). Visually, everything works. As I begin typing, I show up to 5 matches and as I go below that, the list will show fewer items correctly. Here are the how the cells are created and number of rows reported.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "placeCell") as! PlaceCell
if shouldShowSearchResults {
let place = filteredPlaces[indexPath.row]
cell.dataSource = place
} else {
let place = allPlaces[indexPath.row]
cell.dataSource = place
}
cell.delegate = self
return cell
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
if shouldShowSearchResults {
vlog?.debug("Number of FILTERED rows in PlacesTableView: (filteredPlaces.count)")
return filteredPlaces.count
} else {
vlog?.debug("Number of unfiltered rows in PlacesTableView: (allPlaces.count)")
return allPlaces.count
}
}
Since the PlaceCell is a custom class, here are some details of it:
// I've omitted labels, etc.
class PlaceCell: UITableViewCell {
var dataSource : PlaceView? {
didSet {
if let ds = dataSource {
self.isAccessibilityElement = true
self.accessibilityLabel = ds.getAccessibilityLabel()
} else {
self.isAccessibilityElement = true
self.accessibilityLabel = nil
}
}
}
weak var delegate : PlaceCellDelegate? = nil
override func prepareForReuse() {
self.isAccessibilityElement = false
self.accessibilityLabel = nil
super.prepareForReuse()
}
}
I began noticing a problem when UI Tests using Google's Earl Grey began failing due to multiple cells with the same Accessibility Label. Visually, I didn't understand why this was failing since there was only one cell visible that matched.
Upon inspect the views using Reveal, it seems that, as the count of cells drops below what was the maximum of 5, the old cells are still in the TableView, but hidden. So there is a hidden cell that used to be displaying the same data as is displayed by a different cell.
Any idea why this would be happening? This has worked for a number of months and I'm not sure what's changed.
ios swift uitableview earlgrey
asked Jan 2 at 23:10
markandmarkand
1,2601812
|
show 4 more comments
I have a UITableView used to show search results. As I type, I’m calling Tableview.reloadData(). Visually, everything works. As I begin typing, I show up to 5 matches and as I go below that, the list will show fewer items correctly. Here are the how the cells are created and number of rows reported.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "placeCell") as! PlaceCell
if shouldShowSearchResults {
let place = filteredPlaces[indexPath.row]
cell.dataSource = place
} else {
let place = allPlaces[indexPath.row]
cell.dataSource = place
}
cell.delegate = self
return cell
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
if shouldShowSearchResults {
vlog?.debug("Number of FILTERED rows in PlacesTableView: (filteredPlaces.count)")
return filteredPlaces.count
} else {
vlog?.debug("Number of unfiltered rows in PlacesTableView: (allPlaces.count)")
return allPlaces.count
}
}
Since the PlaceCell is a custom class, here are some details of it:
// I've omitted labels, etc.
class PlaceCell: UITableViewCell {
var dataSource : PlaceView? {
didSet {
if let ds = dataSource {
self.isAccessibilityElement = true
self.accessibilityLabel = ds.getAccessibilityLabel()
} else {
self.isAccessibilityElement = true
self.accessibilityLabel = nil
}
}
}
weak var delegate : PlaceCellDelegate? = nil
override func prepareForReuse() {
self.isAccessibilityElement = false
self.accessibilityLabel = nil
super.prepareForReuse()
}
}
I began noticing a problem when UI Tests using Google's Earl Grey began failing due to multiple cells with the same Accessibility Label. Visually, I didn't understand why this was failing since there was only one cell visible that matched.
Upon inspect the views using Reveal, it seems that, as the count of cells drops below what was the maximum of 5, the old cells are still in the TableView, but hidden. So there is a hidden cell that used to be displaying the same data as is displayed by a different cell.
Any idea why this would be happening? This has worked for a number of months and I'm not sure what's changed.
ios swift uitableview earlgrey
asked Jan 2 at 23:10
markandmarkand
1,2601812
You need to show relevant code;cellForRowAt,numberOfCells- How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem
– Paulw11
Jan 3 at 0:05
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is callingreloadData().
– markand
Jan 3 at 0:48
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())
– markand
Jan 3 at 0:59
|
show 4 more comments
I have a UITableView used to show search results. As I type, I’m calling Tableview.reloadData(). Visually, everything works. As I begin typing, I show up to 5 matches and as I go below that, the list will show fewer items correctly. Here are the how the cells are created and number of rows reported.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "placeCell") as! PlaceCell
if shouldShowSearchResults {
let place = filteredPlaces[indexPath.row]
cell.dataSource = place
} else {
let place = allPlaces[indexPath.row]
cell.dataSource = place
}
cell.delegate = self
return cell
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
if shouldShowSearchResults {
vlog?.debug("Number of FILTERED rows in PlacesTableView: (filteredPlaces.count)")
return filteredPlaces.count
} else {
vlog?.debug("Number of unfiltered rows in PlacesTableView: (allPlaces.count)")
return allPlaces.count
}
}
Since the PlaceCell is a custom class, here are some details of it:
// I've omitted labels, etc.
class PlaceCell: UITableViewCell {
var dataSource : PlaceView? {
didSet {
if let ds = dataSource {
self.isAccessibilityElement = true
self.accessibilityLabel = ds.getAccessibilityLabel()
} else {
self.isAccessibilityElement = true
self.accessibilityLabel = nil
}
}
}
weak var delegate : PlaceCellDelegate? = nil
override func prepareForReuse() {
self.isAccessibilityElement = false
self.accessibilityLabel = nil
super.prepareForReuse()
}
}
I began noticing a problem when UI Tests using Google's Earl Grey began failing due to multiple cells with the same Accessibility Label. Visually, I didn't understand why this was failing since there was only one cell visible that matched.
Upon inspect the views using Reveal, it seems that, as the count of cells drops below what was the maximum of 5, the old cells are still in the TableView, but hidden. So there is a hidden cell that used to be displaying the same data as is displayed by a different cell.
Any idea why this would be happening? This has worked for a number of months and I'm not sure what's changed.
ios swift uitableview earlgrey
asked Jan 2 at 23:10
markandmarkand
1,2601812
I have a UITableView used to show search results. As I type, I’m calling Tableview.reloadData(). Visually, everything works. As I begin typing, I show up to 5 matches and as I go below that, the list will show fewer items correctly. Here are the how the cells are created and number of rows reported.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "placeCell") as! PlaceCell
if shouldShowSearchResults {
let place = filteredPlaces[indexPath.row]
cell.dataSource = place
} else {
let place = allPlaces[indexPath.row]
cell.dataSource = place
}
cell.delegate = self
return cell
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
if shouldShowSearchResults {
vlog?.debug("Number of FILTERED rows in PlacesTableView: (filteredPlaces.count)")
return filteredPlaces.count
} else {
vlog?.debug("Number of unfiltered rows in PlacesTableView: (allPlaces.count)")
return allPlaces.count
}
}
Since the PlaceCell is a custom class, here are some details of it:
// I've omitted labels, etc.
class PlaceCell: UITableViewCell {
var dataSource : PlaceView? {
didSet {
if let ds = dataSource {
self.isAccessibilityElement = true
self.accessibilityLabel = ds.getAccessibilityLabel()
} else {
self.isAccessibilityElement = true
self.accessibilityLabel = nil
}
}
}
weak var delegate : PlaceCellDelegate? = nil
override func prepareForReuse() {
self.isAccessibilityElement = false
self.accessibilityLabel = nil
super.prepareForReuse()
}
}
I began noticing a problem when UI Tests using Google's Earl Grey began failing due to multiple cells with the same Accessibility Label. Visually, I didn't understand why this was failing since there was only one cell visible that matched.
Upon inspect the views using Reveal, it seems that, as the count of cells drops below what was the maximum of 5, the old cells are still in the TableView, but hidden. So there is a hidden cell that used to be displaying the same data as is displayed by a different cell.
Any idea why this would be happening? This has worked for a number of months and I'm not sure what's changed.
ios swift uitableview earlgrey
ios swift uitableview earlgrey
asked Jan 2 at 23:10
markandmarkand
1,2601812
asked Jan 2 at 23:10
markandmarkand
1,2601812
edited Jan 3 at 0:40
markand
asked Jan 2 at 23:10
markandmarkand
1,2601812
asked Jan 2 at 23:10
markandmarkand
1,2601812
asked Jan 2 at 23:10
markandmarkand
1,2601812
1,2601812
You need to show relevant code;cellForRowAt,numberOfCells- How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem
– Paulw11
Jan 3 at 0:05
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is callingreloadData().
– markand
Jan 3 at 0:48
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())
– markand
Jan 3 at 0:59
|
show 4 more comments
You need to show relevant code;cellForRowAt,numberOfCells- How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem
– Paulw11
Jan 3 at 0:05
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is callingreloadData().
– markand
Jan 3 at 0:48
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())
– markand
Jan 3 at 0:59
You need to show relevant code;
cellForRowAt, numberOfCells - How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem– Paulw11
Jan 3 at 0:05
You need to show relevant code;
cellForRowAt, numberOfCells - How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem– Paulw11
Jan 3 at 0:05
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is calling
reloadData().– markand
Jan 3 at 0:48
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is calling
reloadData().– markand
Jan 3 at 0:48
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:
EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())– markand
Jan 3 at 0:59
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:
EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())– markand
Jan 3 at 0:59
|
show 4 more comments
1 Answer
1
active
oldest
votes
It is always perilous when you traverse the view hierarchy; things can change, and perhaps that is what has happened here.
Regardless, you can make your test more robust by only selecting the visible item with the required label by using grey_sufficientlyVisible
Something like:
grey_allOf(grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix"), grey_sufficientlyVisible(), nil)
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
That fixed it! Thank you.
– markand
Jan 3 at 15:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014364%2fuitableview-reload-leaves-old-cells-in-tableview-but-hidden%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It is always perilous when you traverse the view hierarchy; things can change, and perhaps that is what has happened here.
Regardless, you can make your test more robust by only selecting the visible item with the required label by using grey_sufficientlyVisible
Something like:
grey_allOf(grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix"), grey_sufficientlyVisible(), nil)
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
That fixed it! Thank you.
– markand
Jan 3 at 15:08
add a comment |
It is always perilous when you traverse the view hierarchy; things can change, and perhaps that is what has happened here.
Regardless, you can make your test more robust by only selecting the visible item with the required label by using grey_sufficientlyVisible
Something like:
grey_allOf(grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix"), grey_sufficientlyVisible(), nil)
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
That fixed it! Thank you.
– markand
Jan 3 at 15:08
add a comment |
It is always perilous when you traverse the view hierarchy; things can change, and perhaps that is what has happened here.
Regardless, you can make your test more robust by only selecting the visible item with the required label by using grey_sufficientlyVisible
Something like:
grey_allOf(grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix"), grey_sufficientlyVisible(), nil)
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
It is always perilous when you traverse the view hierarchy; things can change, and perhaps that is what has happened here.
Regardless, you can make your test more robust by only selecting the visible item with the required label by using grey_sufficientlyVisible
Something like:
grey_allOf(grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix"), grey_sufficientlyVisible(), nil)
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
answered Jan 3 at 8:44
Paulw11Paulw11
70.3k1090105
70.3k1090105
That fixed it! Thank you.
– markand
Jan 3 at 15:08
add a comment |
That fixed it! Thank you.
– markand
Jan 3 at 15:08
That fixed it! Thank you.
– markand
Jan 3 at 15:08
That fixed it! Thank you.
– markand
Jan 3 at 15:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014364%2fuitableview-reload-leaves-old-cells-in-tableview-but-hidden%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You need to show relevant code;
cellForRowAt,numberOfCells- How you are accessing cells in the test. Preferable create an Minimal, Complete, and Verifiable example that reproduces the problem– Paulw11
Jan 3 at 0:05
Paul - I've added some of the code. A few points.
– markand
Jan 3 at 0:41
Tried to modify the comment, but took too long...(continued) First, the cells are always showing correctly, and the debug logs show that, for example, numberOfCells is returning the correct count. Also, prepareForReuse is being called properly for all cells that are reused, but for the ones that remain hidden, it's not called. As for your question as to how I'm accessing the cells in the test, I'm not. I'm typing in a search box which is calling
reloadData().– markand
Jan 3 at 0:48
But you said that a test is failing; you must have test script that you are using. It may well be an issue with Earl Grey. Anything that crawls the view hierarchy is at risk of having issues if Apple changes what happens under the hood. You said yourself that Reveal shows that the cells are there. If Apple simply makes them hidden and it gives the right visual output, then they can do that.
– Paulw11
Jan 3 at 0:54
Understood. This is also happening without Earl Grey. If I run the app and simply type in the search bar, when the count of items drops down below where it was (i.e. 5, which is the max), and I inspect the view using Reveal, I see the hidden cells. Where the Earl Grey test fails is simply trying to select the row and tap on it:
EarlGrey.selectElement(with: grey_accessibilityLabel("Whole Foods Market, East Mayo Boulevard, Phoenix").perform(grey_tap())– markand
Jan 3 at 0:59