I think that's maybe better resolved with T7004. My concern is this solves no new problems (or problems we're already tracking and would resolve in other ways). I prefer email notifications when out and about on my phone since they contain more information and are easily replied to. Push Notifications seems like a step backwards from a usability perspective.

I have email notifications disabled wherever possible. When I shut down my computer, it'd be super useful to be able to get push notifications to my phone.

What problem does Push Notifications solve that other notification mechanics, like say email or desktop notifications, don't solve? I'm not saying we'll never do this, just it seems exceedingly complex and generally marginal actual value.

Actually the same problem if you are looking at the result of a query in Maniphest, so it's a generic problem.

In T8878#126901, @chad wrote:

I'd rather over-engineer a more generalized "new in phabricator" type feature, so people understand what new functionality was added since their last update.

Safari's Push Notifications for Websites, for example, sounds pretty awesome.

I don't think desktop notifications in it's current state is worth additional touting (it doesn't do Conpherence, for example). Even if it were, I'd rather over-engineer a more generalized "new in phabricator" type feature, so people understand what new functionality was added since their last update.

The slack way of doing think can be a possibility, no ?

Woah, same thing for me. Had no idea.

When we do this, I think I'd like to keep the persistent "This page has been updated" notice.

Did you have something specific in mind? It feels about right to me. "New" settings are always going to be somewhat under-discovered.

I can't think a better means of handling this, and at least if you're an admin testing notifications, it seems more important that they're easily found and not automagically dismissed.

This seems to be stable now, I don't immediately see any more ridiculously dumb slow stuff in the /feed/ profile. Remarkup handle fetches are still a bit loopy but that's a topic for another task.

Cheers!

Also, Herald is intentionally stronger than self-actions.

This is a very niche use case. It also tends to conflate the pusher (who we may not know, for imported repositories), the committer, and the author. This makes me hesitant about implementing it.

This seems to have resolved itself (after I pushed?) so I now have zero repros. Assuming I am just insane.

For instance.. your action there just gave me an email I didn't want. But I guess you guys must know this, already.

On our install, this data is ~250MB.

I belive in our case it may have been a case of bad SSL config.
It no longer reproduces on our setup.

I may be having this same issue.

Yeah, the second issue should be fixed in HEAD, see T8112.

Does anyone have a use case for this which isn't maintenance notifications?

See also: T5231

I don't think this is worth fixing in general. It doesn't do anything bad (just dump a warning to a developer log which users normally don't see) and fixing it isn't trivial.

I removed this as a blocker for shipping Quicksand, though shipping Quicksand may help obviate this issue since we will do less page loads.

In T7897#108576, @epriestley wrote:

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

Event listeners do, generally speaking, respect middle and right clicks. This isn't a case of event listeners just being too ambitious.

I wanted to test it and... Clicking Links in notifications work flawlessly regardless of durable column. Clicking notifications themselves opens in same tab regardless of durable colum state.

The plot thickens...

As much as I hate features, this is relatively easy to build from a JS/eng point of view, fixes T7132 more easily than giving it a real target, and might let us just not pursue T7843.

Oh, just realized you probably meant the Facebook notifications dropdown. That has the same single line that may overflow to many lines problem, and they use consistent padding / space on the right hand side to work around it.

I was just guessing at a possible cause, especially as I am working to get Quicksand in a better state. Its only in play if the durable column is open. Basically, don't mind me. :D

We've messed with a bit but do not actively use it. The ctrl-click and middle-click on notifications don't seem to work on secure.phab either (unless you're implying that maybe quicksand made them work?)

Do you all use the durable conpherence column perchance? (Hit "\" to check it out if you have no idea what I am talking about.)

Almost certain it did. Updated last night and one of my users called this out first thing in the morning. Not sure exactly which version I updated from, but my database dump from the previous update was timestamped phab.20150407_034445Z.sql.gz

I think we currently keep "someday" tasks open - even if we can't predict when someday is - so I'm re-opening. (I like to update tasks from the "need triage" aggressively so definitely feel free to change my updates if I'm wrong.)

This is doable, but not something the upstream devs would likely build in any reasonable timeframe. 

As far as I know this has never worked. See T6700. This is likely a duplicate on how we listen to clicks on all menus.

kk. As a note, in my opinion at least, I think the main burden is not that it has to be clicked, it's that often I don't want to leave the page I'm on. So what I do now usually is just open in new tab and then immediately close the new tab.

I heard you. :D