amcbain / relove Goto Github PK

Long chat messages that don't wrap create a horizontal scrollbar. This is bad, because being that it is all in a table, when the table stretches out all other lines will stretch out too, not just the troublemakers.

An example of a reLive show with this problem is Scenes from the Burgh on 2014-12-28. At about 12:04 in the chat log (2014-12-28 20:04:25 in the tooltip) several messages by a user "zeg" show up that have no spaces or natural break points in them.

This can be fixed many ways, but most solutions are subpar. Of those, I've tried:

• table-layout: fixed; (username column no longer resizes to fit contents)
• Inserting between each character of a message (could cleave normal words at odd points)
• Inserting a zero-width space between each character (it gets copied with the regular characters)
• Inserting a soft-hyphen between each character (same as zero-width space)
• Overriding the table styles with flexbox ones (the username elements are no longer the same width)
• Setting a dynamic max-width and word-wrap: break-word; on the last td of each row

(Most of those solutions also take a long time when rendering a large amount of the chat log to catch up to where the user requested playback to be or when loading a link to a stream further in.)

The last solution above is the most promising but requires the most work. In it the max-width for the last td is set to the width of the parent minus the scrollbar, the width of the first td, and the width of the second td. The problem is if someone resizes the browser it will be too short until the next message is posted and it is recalculated. To ensure that it isn't recalculated on every insertion, a timeout can be used that is cleared on each new line with a very low value, such as 1, so that if a bunch of lines are inserted at once only the last one triggers the change.

Except for the window resizing, this isn't the worst solution in the world. The window resizing requires tying in to such an event which as an element that is created and torn down many times (potentially) during the lifetime of the app is a bad idea to leave hanging around. There is no repaint method like the annotated player, but one could be added to handle the event from the Replayer in the same way.

(It may also need to check if the chat area should scroll down after the fix, as it's possible that it could jump due to the additional vertical rows that now exist and it will execute after the scrollbar is pushed down due to the addLine check.)

If entering a show and goes back to the stream listing, the scrollbars are gone, meaning you can't scroll in the listing any longer.

In Chrome just use the scroll wheel. In Firefox use the middle click then move the mouse down. One way to fix this might be to kill the scroll event by preventing the default when there isn't supposed to be a scrollbar. Add the event when not scrolling allowed there and remove it when it should be allowed again.

#track-1-D6-0 is not recognized but it's used by the search listings on the SceneSat page. Needs to be fixed.

Using https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/buffering_seeking_time_ranges it is possible to show the buffered progress (even individual segments if the user skips around) as a translucent black overlay. To be unobtrusive such a thing could be shown along the bottom as a one or two pixel set of lines until the entire file is buffered, then it goes away.

This would help slow connections for people who want to skip around and until range requests are implemented it'll let any savvy beta testers in to how far ahead they can seek.

The left edge for initial narration on "s:startup-sequence" show looks like it doesn't go all the way up on the left and all the way down on the right. Needs one more bar each.

The ChatView should own and display its own log. It should get events somehow hooked up so it knows when to advance. Take the responsibility out of replayer.js

https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers

I believe at least Firefox and Chrome can handle the above. It seems you could have something that knows what to do with "relive:" based in the web. The browser would take it and pass it off to the web app as #relive:stream-8-3G but this has a few potential issues and questions.

1. What happens if the user allows the web app to have relive and later installs the desktop app? Which gets relive requests?
2. Does doing that in the reverse order cause the web app to be prioritized over the desktop app? (or just fail to register)
3. Can a user uninstall the reference to the handler at a later date if they choose? (In Firefox it doesn't seem like there's an easy way to do so.)
4. Would users actually see this as a useful feature?
5. Does the web app ask automatically only ask when a menu item is clicked?*

* Of course it would only ask once as long as a localStorage value persists so that if it was asked once it doesn't keep asking. If it was based on a menu item, then if the user declined it after clicking the menu item, the menu item would remain if isProtocolHandlerRegistered exists and can tell us otherwise it would be hidden and squashed in the future by the localStorage value. If localStorage doesn't exist it would seem better not to ask at all even if the function to do exists so that the user isn't asked every time on start. Especially since if the protocol is already registered by the site asking again presents a message to the user. :-/

It only shows the segment's title. It should be the same as everywhere else: artist - title.

The app spends too much time trying to keep the chat log up to date as it has to go through all the items since the current time stamp.

Shouldn't be that hard, there's not that many chat types (0 to 9) to document what they are and what shows up in each column for that type. Also include which element to apply the background to for people who want a dark one.

It's already possible from the app menu (like all other similar actions) and in the context menu for tracks in the track list. However there doesn't seem to be any reason why you can't just right click in the middle of a track and get a URL to the start of it.

Make chat log timestamps clickable and seek to that point in a show.

If support for history.pushState exists, then push states for the various application actions:

• Clicking to the list of stations vs latest streams list
• Clicking in to a stream

If history.replaceState is supported, when pausing replace the last state if it has a hash to be the current value. The hash is already changed on pause, but this adds a new history item. It would seem odd to hit back and cycle through all the locations that were paused at. (This does mean though that if someone arrives at the app via a URL with a hash, hits pause, then hits back, then goes forward again they'll land at the paused location not the original one they started with. However I don't think that's a huge problem.)

The previous hinges on the popstate event support, though. Check that first.

The hashchange event could be used to sort of work around the lack of history events, but it's kind of crude and would end up with the issue noted above where you'd end up skipping back through the stream based on whenever you decided to pause it. Doesn't really seem worth it.

1. Load a fresh tab with https://temps.asmcbain.net/reLove/#track-1-D5-FP
2. After it starts playing, set the URL bar to https://temps.asmcbain.net/reLove/#stream-1-DB and hit enter

Need to make sure that if it's in the same stream, we seek, if it's not, we switch to the new one.

CSS now has the concept of variables, which work on the client-side. Browsers that don't support variables would just ignore them and, presumably, that support could be determined with a quick check.

If variables are supported, then a menu item could be added to offer an overlay/dialog of some sort that lets them pick and stores the result in localStorage so it sticks every time they return.

This isn't a big deal since most usages of this app would be embedded, at least as far as I know, and so anyone deploying it would probably configure it in the stylesheet to their preferences so everyone visiting has the experience they desire.

The scrollbar can get stranded like if the user scrolled it up based on certain messages. Presumably large messages are what does it as their addition causes the check after insertion to determine the scrollbar is too far away from the bottom.

I think the solution is to check whether or not the auto-scrolling should be performed before inserting the new line, then doing the scroll down after the insertion.

Seems that as this is a web app, it could also be suitable to use with an iframe as an embedded deal. The base version as it stands now would get a bit clunky with support added for this not to mention the overhead of having to wait for all the stations and streams to load before getting around to the one the iframe URL asked for.

The current relive.js API just needs a station ID to load the list of streams for a station or a station ID and a stream ID to load a specific show. Thus a URL could, through base 62 encoding, give the details of what to load. These URLs are already generated by the app (or other reLive apps) so they're suitable for easy use here.

A separate embed.html can load an embed.js (separate from app.js) to set up a version that does only what is needed. An embedded version for a specific show should not have a back button, and those for a given station should show only that station.

The progress area uses a progress tag, which doesn't show up until IE10. It's not necessarily that hard to do, just make it behave like the volume elements do. I'd rather I be able to use progress and meter for both, but IE decided not to support the meter tag.

Seeking and brushing (tooltip) should still work in IE9, it just won't render or advance the position indicator. So users on IE9 won't know where they are in the stream except by announcement within the audio.

Part of the menu? (kinda icky, but very visible) Show on start but fade out? I dunno, something. By request of @Ziphoid so he can tell which version is live if caching issues show up.

It is too high relative to the volume icon. It should be in line with it.

Currently the code just sets a CSS class of 'bad' on the progress area, which floods the background with a bunch of exclamation point like drawings. It would be useful to indicate to users why this happened. This info is helpful in trying to fix it or indicating lack of browser support for some things.

Chrome doesn't like custom implementations of range requests even if the support conforms to the specification. Ziphoid noticed this here and I also in one of my own personal apps. A fallback for this would also cover websites that don't support range requests.

If the seeking takes more than X seconds (5, 10?) set a flag and do all further seeks (until page refresh) by changing the stream URL to have a start parameter that corresponds to the desired location.

From what I remember of what Ziphoid told me this requires knowing the bitrate as the start position is in bytes, not seconds. (This would make sense if the server-side was done naively, as it is very easy to do and format agnostic.)

This is listed as a bug because the seeking doesn't do what users expect it to if range requests fail. It makes the app much less usable for those who want to skip around.

This will stop accidental selection of text. Crucial (I think) for mobile users who might push down and swipe to see the tooltip.

This project is all in raw HTML and JavaScript with no library dependencies. This means it can be made packaged very small, if you're willing to bother. It also has no build environment requirements or any new fancy features helpful to developers.

Many parts of this will become Components making it very easy to add the component anywhere inside of a React app.

The replayer area isn't getting the correct height by default and is only as large as the contents currently in it. This means it only shows the progress area by default and grows as chat lines are added. It does not seem to have a bounded height like it should and will continue past the height of the viewport as it grows.

Maybe move to ditching calc here and use a fixed height for the section based in vh? The contents are already mostly absolutely positioned. The header can be left alone and the chat view can be moved to absolute positioning. One less calc is probably for the better.

(Incidentally this particular issue doesn't show up in the various notes on caniuse.com or via a Google search. It could possibly be isolated, but like a prior bug worked around it may prove hard to make in to a test-case. Caniuse also indicates the usages of calc in this project do not run afoul of prior lacking Android implementations, though only direct testing on such devices will tell. Theres's also no rush to remove them all in favor of other styles due to an informal minimum of IE9, which supports calc, for this project.)

If a request to get data via the relive.js library fails, it isn't handled. This is largely due to the fact that the library has no error handling trap short of replacing ReliveBinaryRequest with a patched version that handles errors.

So if you start up the app over https, Firefox (and probably Chrome too) will block the requests because they're less secure than what the page itself was served over.

The middle line is drawing too high and too close to the top line.

Blocked by #39

Open a dual-chat stream and wait seek ahead to a point where the non-visible stream has more lines than can be shown without scrolling. It should be scrolled to the bottom, but isn't.

Update the URL to include the current location within the app (what stream is being viewed) and [on pause?] indicate where in that stream the user is. This makes it easy to bookmark things to come back to them later, or share them with others. (Very much similar to the links generatable by the desktop reLive app.)

When pointing the user directly to a stream, it would be good to leave them a way to get back to all shows as well.

This means removing colors, skipping the first 1s identifier block if it exists, and alternately painting every other segment.

font-family: Consolas, monospace;
font-size: .8125em;

This will make it consistent between Firefox and Chrome at least.

As the title says. Just show the location while dragging (active update) instead of only after mouse up.

It is currently set to 75% but the max width is kind of small, so at such point it should just take up the full width instead to give people as much room as possible.

Seeing as one bug has been discovered in Safari due to calc, and the relative newness of the feature, it seems that the project may benefit, perhaps in unforeseen ways, from the removal of this crutch to get going so quickly.

The bottom value for the segments sidebar is an easy candidate for removal, given that a bottom value + a margin-bottom can achieve a similar effect to the current use of calc there.

Like the desktop app, offer the ability for a user to see the entire chat log for the current show at once.

When clicking a stream then switching back you're scrolled to the top. It should put you back where you were.

One line text is used in a lot of places, and it could have a tooltip if it overflows or something else to indicate what the rest of the text is. Other options could include adding styles to properly handle multiple lines in those places.

Places using single lines currently include: stream listing heading and host lines, the page header area, the segment list, and the title area above the progress section.