Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Use Markdown for this comment
Set severity, which reflects how much the issue affects the use of the product
Change issue status back to 'Assigned'
Pending code changes (auto-populated)
[ID: 84651]
Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Each team will estimate work on a slightly different scale, which means the values in this field are likely only meaningful to the team that owns the Buganizer component in which the issue resides.
See Atlassian's Agile Coach for more information on how to use story points for estimation: https://www.atlassian.com/agile/project-management/estimation [ID: 746686]
Set the version(s) of the product affected by this issue (comma-separated list)
Set the version(s) of the product in which the issue should be fixed (comma-separated list)
Set the version(s) of the product in which the issue fix was verified (comma-separated list)
Set if this issue occurs in production
[ID: 85206]
Set Reporter
Set Type
Set priority, which reflects how soon the issue should be fixed
Set Status
Set Assignee
Set Verifier
Remove item
View or edit staffing
View issue level access limits(Press Alt + Right arrow for more information)
Attachment actions
Description
Component used: Fragment
Version used: 1.2.0-rc04
Devices/Android versions reproduced on: all
If you commit a reordered postponed transaction, followed by a non-reordered transaction (postponed or not), the non-reordered transaction can be executed before the postponed one. That means that transactions will be executed out of order and the final state of the app will be incorrect. This happens because non-reordered transactions completely ignore postponed transactions and are executed indiscriminately.
The attached sample commits two FragmentTransactions in the onCreate of the activity..
The first is a replace of with postponed fragment with a postponed timeout of 4 seconds that is reordered and the second is a replace with non-postponed fragment that is not reordered.
The postponed fragment has a purple background while the non-postponed fragment has a blue background.
Expected behavior:
The app is launched.
The reordered-postponed transaction is committed, then the non-reordered transaction is committed.
The postponed transaction is forced to execute immediately before the non-reordered transaction is executed.
The final state of the app is the non-postponed fragment with the blue background.
Observed behavior:
The app is launched.
The reordered-postponed transaction is committed, then the non-reordered transaction is committed.
The non-reordered transaction is executed immediately, but does not force the postponed transaction.
The blue background appears.
Once the postponed timeout finishes, the postponed transaction is executed.
The final state of the app is the postponed fragment with the purple background.