Closed Bug 829220 Opened 11 years ago Closed 6 years ago

Scrolling on trulia.com eventually locks up

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-, b2g18+)

RESOLVED WONTFIX
blocking-basecamp -
Tracking Status
b2g18 + ---

People

(Reporter: bjacob, Unassigned)

References

Details

STR:

1. I reproduced this on an Otoro phone
2. go to trulia.com
3. tap the search icon (the looking glass)
4. tap search (the default search is for Los Angeles)
5. scroll down through the results

Actual result: the scrolling eventually locks up, it becomes impossible to scroll up or down. The back button still allows to get out.

Got this while trying to reproduce bug 824777 on an Otoro.
Step 2.5: tap "homes for sale". This is exactly the STR of bug 824777 comment 11.
Oh, flinging then allows to un-lock the scrolling. Could be specific to TrackTouch scrolling.
blocking-basecamp: --- → ?
jlebar, is this what you fixed yesterday?  something about 'Holding a lock while calling out to other code' in the panning controller.
Flags: needinfo?(justin.lebar+bug)
(In reply to Doug Turner (:dougt) from comment #3)
> jlebar, is this what you fixed yesterday?  something about 'Holding a lock
> while calling out to other code' in the panning controller.

The browser wasn't using the code which triggered the deadlock fixed by bug 828969.  Also, it was a permanent deadlock in the main process, unlike what's described here.

However, as described, this bug sounds a lot like it will be fixed by switching the browser to mozbrowserasyncscroll, which we should be able to do now that bug 828969 has been fixed.
Flags: needinfo?(justin.lebar+bug)
The relevant browser bug which may fix this is bug 797633.
going to make this blocking on 797633 for now.
Depends on: 797633
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.