drawer-state: new stacks broken

RESOLVED FIXED in M2

Status

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: gbrander, Assigned: sfoster)

Tracking

({regression})

unspecified
x86
Mac OS X
regression

Details

(Reporter)

Description

7 years ago
What I expect:

1. Type a search
2. Click on a link
3. Viewer displays link page
4. New stack added to stack list
5. Stack is made active -- stack contents are shown
6. Site is highlighted as active in stack

What happens:

1. Type a search
2. Click on a link
3. Viewer displays link page
4. ...nothing

Refreshing the page displays the new stack in the list.
(Assignee)

Comment 1

7 years ago
This is fixed in the browser (/views). We are having persistent issues now in iOS, where this is a symptom. It appears that the cross-window messaging to the 'top' window to load stuff into the drawer is not working, and this (and lots of other stuff) relies on it.
Status: NEW → ASSIGNED
(Assignee)

Comment 2

7 years ago
Now fixed in both browser and iOS. 
There were several issues, all ultimately resulting from the limited visibility into the JS we get in iOS. There were logger bugs, bugs arising from the difference between the browser xmessage lib and the iOS message thing, and countless others. 

To cap it off, the coordination of the uiwebviews from javascript was hopelessly brittle and vulnerable to race conditions. 

This has been addressed by: 
* a handful of functions in lib/objecttools for inspecting and serializing objects. JSON.stringify will throw on some values (e.g. ErrorEvent objects)

* Reworking the ios logger to try/catch, (hopefully-)safely serialize before sending, and using an iframe.src transport rather than the window.location assignment

* Reworking the handshake between windows to send 'ready' and wait for a reciprocal 'readyAcknowledged' message.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.