When swimming, the player can stand up even though there is a block above

Confirmed in 18w19b

I don't think this should be marked as fixed. The change that was made in 18w20a seems to have to do with canceling your sprint as well as making you float upwards slightly as soon as you look above the horizon point of your view, but that aside, this fix only works when opaque solid blocks are above you, not transparent ones (I say "opaque" and "transparent", but what I really mean are any blocks that attempt to push you out of themselves versus blocks that don't). So a situation like what's shown in the screenshot/video still happens in full force, since the blocks above are glass, and glass doesn't push you.

All that said, the root of this problem seems to stem from entering the elytra's 1x1 hitbox mode when this bug happens. When they originally fixed the players' hitboxes during elytra flight to actually be as small as they looked, they didn't bother to fix literally everything else that should have come with that, like the eye level when sneaking, or the player model visually standing up after landing in a 1-block high gap despite there being no room to stand, or solid blocks (except the non-pushy ones) just above you still attempting to push you towards nearby air as if you still had a full hitbox (it's difficult to cleanly fly through a pushy 1x1 gap without a firework, and a 1-tall, 3-or-deeper gap is doable but VERY difficult, and such gaps are actually impossible to force through with only a single firework... To win against the pushback with fireworks apparently requires the extreme acceleration (not max speed; that's capped as far as I can tell) of literally 3 fireworks at once), etc. (or is there an "etc."? I think that's actually already most if not all of the major elytra issues that are still somehow around after 2.5 years...).

In other words, what basically should have probably happened was to first fix the core of the problem (the elytra bugs) rather than treating its strangely related symptoms (swimming bugs) with puzzling workarounds (why does the current fix have to cancel your sprint (doesn't prevent sprinting, just stops it if you're not holding forward when you look above the horizon, but maybe swim sprint was never intended to stay active? I'm rambling on about this part because 1.13 is the first time you've been able to sprint in all 4 directions, even if it's only "swim" sprinting and requires you to be touching the floor)? Why does looking above 45° apply slight upward motion so powerful that it absolutely cannot be prevented by sneaking without the help of a magma bubble column? And why doesn't "swimming" in air-filled gaps require any of these things?).

Anyway, some sort of crawl animation might be good for any situations where the player initially lands/swims into a 1-block high air gap. Beginning to think there should just be some kind of crawling ability at this point of the game, but I imagine it's probably simpler for now to just have a separate animation for "swimming" in air gaps (nearby dolphins still buff you if you're "swimming" in air by the way (as in proper swimming animation, not elytra's 1x1 mode), but that might be something to report in a new issue if it doesn't already exist).

P.S. Whatever coding magic was used to fix MC-125240 feels exactly like what the elytra bugs need! Also, I think this issue technically relates to MC-125085.

It's indeed not fixed. I'm still able to reproduce in 18w21b.

So I was meaning to comment again during 1.13-pre3, because while I hate to say it, I found out by chance that it's still possible to trigger this bug. XD However, MC-132064, a new bug in 1.13-pre4, mostly prevents this bug from occurring due to being almost completely unable to get out of the swimming animation while on land. All that aside, here's how you trigger it again in 1.13-pre4:

Swim into a 1-tall gap (whether or not the gap itself has water in it doesn't matter), and then poke your head out from under the block (for easier testing, make sure the block you're poking out from is one that doesn't push you out of itself) without moving completely out from under the block. If directly above the middle of your hitbox is water of any kind (or, if this was before 1.13-pre4, this would also include air/any other non-solid block that would normally allow you to stand back up), you enter elytra's 1x1 hitbox mode just like before, a.k.a. "visually standing up inside blocks". Coincidentally, this is how you escape the aforementioned new bug (it's escaped by having any kind of water block 1 block above your feet level, even if your feet level itself isn't in water). I'll write about that over there too.

The fix for this needs to check if your whole hitbox would be able to stand up (just like how the sneaking hitbox works; you can verify the sneak hitbox thing for yourself with a carpet and a trapdoor on the top half of a block directly above it), rather than only checking the block directly above your x/y/z coordinate (at least I assume that's primarily how all this swimming stuff is detecting whether or not to start/stop swimming).

I really think elytra's 1x1 mode just needs to be (or transform into) the land version of swimming (if land swimming is even actually intended anyway). Its bugs need to be properly fixed first of course, but 1-tall gap travel's technically been possible ever since flying minimized your hitbox. Another reason I bring this topic up again is because I believe it functions similarly to the sneak hitbox in that it only fully stands up once there's room for the entire hitbox. Bugs may make it look/act weird, especially the push-back one when trying to get through a gap, but it still only stands up when there's room for the entire hitbox. Also, it doesn't seem like sneaking/elytra 1x1 mode checks for required blocks to stand back up, but rather, just checks if the top of the hitbox would collide with anything solid. From what I can tell with swimming, it requires completely non-solid blocks (well, in the case of 1.13-pre4, it's solely water for now) to stand up rather than basing it on whether the hitbox has room.

P.S. Seems that elytra push-back bug starts when there's a "push-you-out" block up to 1.5 blocks above your feet level; if you're even 0.00000000000001 lower than that (by the way that number is the smallest possible teleport increment), then it won't push you away.

Yes, this is indeed still not fixed.

Looks like 1.13-pre5 also re-broke it in the sense that its behaviour is exactly back to the way I described in my first wall of text (meaning blocks above you that aren't of the "push-you-out" variety cause you to enter elytra's 1x1 mode again).

Sounds like 1.13-pre6 may have fixed it again, but I haven't tested it yet. Can someone else try it?

Seems to be fixed for MC 1.13-pre6.

Nope, it's not fixed.

1.13-pre6 has it acting the way it was before 1.13-pre5, so it's back to happening in the way I described in my second wall of text this time. In short: elytra's 1x1 mode is entered if the middle of your hitbox would have room to stand up, but not the rest of it (seems to me like swim mode is checking for certain blocks directly above your x/y/z coordinate instead of checking whether the player's hitbox would collide with something solid like sneaking/elytra's 1x1 mode seems to do).

As an extra note, the reason I said "any non-solid block that would normally allow you to stand back up" in my second wall of text is because apparently some partially solid blocks don't allow you to stand back up even if there's actually room. For example, closed trapdoors one block above you on the top half of a block won't allow you to stand up even though there's room to do so (unless you jump out of the water to get to the next y coordinate, assuming there's also a "stand-up-able" block above the trapdoor (which causes you to enter elytra's 1x1 mode since the trapdoor is in the way at that point)). Yet when they're open, they're treated entirely like a block you can stand up in (triggers elytra's 1x1 mode if your hitbox would collide with it; no secondary blocks needed).

Piston heads are pretty much the same; swim under a couple of them and you won't be able to stand up between them despite there being room.

Speaking of this bug and trapdoors, I imagine trapdoors in particular are gonna be a guaranteed way to enter elytra's 1x1 mode as long as the game continues to only check for stand-up-able blocks 1 block directly above the x/y/z coordinate of the player, since there's room for players to crawl right underneath trapdoors (therefor it'll almost always only be checking the block above the trapdoor).

I know I sound like a broken record here, and I'll try to stop mentioning it after this, but if the elytra's 1x1 mode got fixed (pushback and the sneak eye level bugs), and was given a dedicated crawling animation while not flying (perhaps even just a copypaste of the swim one), then wouldn't most of these issues disappear? I mean, ever since around the introduction of swimming mode, it seems like the elytra's 1x1 mode was being utilized as some kind of swimming fallback, so the framework feels like it's already there. Would just need to match up the eye level and sprinting differences between the two as well, and bam all set!

Alternatively, if swimming becomes fine-tuned enough to not even need the backup of elytra's 1x1 mode, then that's just as well (albeit a shame since the elytra bugs would probably continue to get left alone, haha).

Seems to be fixed in 1.13-pre7, at least I cannot reproduce it anymore.

Edit: ... aaaand I just managed to reproduce it again.

I attached a video of it happening in 1.13-pre7. If the blocks above the water are solid, you'll get quite in serious trouble if you're in survival mode.

I'm not able to recreate the issue in 18w31a. I built what was shown in the picture. I used stone blocks instead of glass. I was sneaking and swimming up in the 1 Block gap with no Damage taken. This might actually be fixed?

The player doesn't take damage anymore, but it gets stuck at the end of the tunnel if there are solid blocks above. I might create a new ticket about this though, this is slightly different from the original bug I reported.

The issue I'm still experiencing apparently is already described by MC-131116