NavItem root element & new compose button

[Ben]

Hi InboxSDK team !

We noticed that Gmail is progressively rolling out a new Compose button, showing a pen icon, instead of a '+'.

With this new UI, it seems like your SDK puts root NavItems inside the 'Mail' section, instead of next to this 'Mail' section as usual.

Our users are a bit lost...

Are you already aware if this issue ?

Are you planning a fix for it ?

Thx ! :)

[flo...@gmelius.com]

Hey InboxSDK team!
+1. Any updates on that change?

[Ben]

Hello there.

Anything new ?

Yes ? No Maybe ?

It could be cool to let us know where you're going with this issue.

[kir...@iriscrm.com]

Are you also feel like this project got abandoned?

Last change from 2 years ago:

2019-06-13 Removed the limitation on ContentPanelView.open() where it could only be used within a user-input event. The limit was made to discourage extensions from being too aggressive with opening the sidebar, but this limit seemed to be too restrictive.

Or Gmail is not that changing these days?

[Cody Duval]

We're also affected by this, curious if there is a fix in the works?

[Chris Cowan]

Sorry for not responding to this thread sooner! It appears there's a bug that causes nav menu items to be placed inside of the Mail section instead of as top-level items specifically when the nav menu is in the force-expanded state instead of the minimized state on page load. We'll address this within the next few days.

[Ben]

Nice ! Better late than never.

Our users are looking forward to seeing this fixed.

Thx ! :+1:

[Ben]

Ouch. Big breaking changes, today.

It's worse than before :/

Our ToolbarButtons are not clickable anymore. We'll have to deploy a quickfix and attach a custom click handler on them...

Accessories are on the left of their NavItems when the big left navigation panel is expanded, and above the icons (unreadable) when collapsed.

Please, address this ASAP.

Thx.

[Ben]

Accessories position was not a big issue. A simple tiny tweak in our CSS fixed the thing.

Mea culpa.

But we do use your API for the Toolbar button click handler. It's not a matter of "conflicting" implementation or API misusage.

I presupposed you fixed something, but it finally looks like another update of the UI from Gmail.

Our last clue : When we disable the style attribute 'pointer-events: none;' from the style class 'ar7' of the inboxsdk__button element, it works just fine.

I hope it will help.

[Aleem Mawani]

See the other thread regarding the toolbar buttons. 

As for the new nav section design, we've seen Gmail test this and roll it back from some users. We're monitoring it to see which way they choose to go. 

--
You received this message because you are subscribed to the Google Groups "InboxSDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/9f690529-076b-4b72-869f-1d9c78a4d5c0n%40googlegroups.com.

[Chris Cowan]

The issue of the nav menu items being embedded with Gmail's instead of in a separate section has been fixed!

There is a situation where it's intended behavior and still happens though: when a user has the "classic hangouts" chat setting turned on. That setting causes Gmail to use an older format of the left-nav menu that's not easily compatible with the current way the InboxSDK prefers to organize navitems. It turned out the InboxSDK had a few subtle bugs that caused it to fall back to the old format in certain cases that are fixed now.