Closed
Bug 597788
Opened 14 years ago
Closed 14 years ago
Pressing the 'Sync Now' button in the new firefox menu/button breaks the firefox menu/button
Categories
(Firefox :: Sync, defect)
Firefox
Sync
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: jhford, Assigned: zpao)
References
Details
(Whiteboard: [testday-9-24-2010])
Attachments
(1 file)
647 bytes,
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
Steps to reproduce:
-launch minefield
-set up sync through the 'Minefield' menu
-click 'Minefield' then select 'Sync Now'
Actual results:
-clicking on the 'Minefield' button does nothing but change the appearance of the button to look like a press
-'Minefield' menu does not appear
Expected Results:
-'Minefield' button continues to show the appropriate menu when pressed.
Workaround:
-press alt to bring up old style menu bar
-select one first level menu entry (file,edit,view...)
-press 'Minefield' and notice that the menu is back.
This only happens once per instance of firefox and is always the first time I click on 'Sync now'. It is always on the first attempt and so far has been 100% reproducable.
Comment 1•14 years ago
|
||
I can confirm this. Starting a manual sync using the Sync Now menu item from the Firefox/Minefield menu prevents this menu from opening for the duration of the sync process. After the sync is complete I can open the menu just fine again. Starting a manual Sync from the toolbar button doesn't seem to cause this behaviour.
Comment 2•14 years ago
|
||
I think the Firefox UI stripped the setTimeout from doSync, which means that menu is locked while the function executes...
Comment 3•14 years ago
|
||
If you have the Menu Bar shown, this bug disables the Tools menu 'til sync is complete.
Updated•14 years ago
|
Whiteboard: [testday-9-24-2010]
Updated•14 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
This bug appears in the in Beta 7 on win 7 64 bit in the same way as described by John.
btw bug#597663 is the same bug
Comment 6•14 years ago
|
||
Either we should call syncOnIdle(0) or call sync() from a timeout.
blocking2.0: --- → final+
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #6)
> Either we should call syncOnIdle(0) or call sync() from a timeout.
syncOnIdle(0) will
(a) fall back to syncOnIdle(5)
(b) bail if there's already an idle observer
(c) create an idle observer
Subsequently, it won't actually "sync now", so I'm going to vote for setTimeout (which is what the extension does... I guess I thought that unnecessary during the conversion as was pointed out in comment 2. oops!)
Assignee: nobody → paul
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•14 years ago
|
||
Attachment #496927 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•14 years ago
|
Attachment #496927 -
Flags: review?(gavin.sharp) → review?(dolske)
Updated•14 years ago
|
Attachment #496927 -
Flags: review?(dolske) → review+
Comment 10•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in
before you can comment on or make changes to this bug.
Description
•