Roadsguy
- roadsguy
- roadsguy
- America/New_York
- Yes
- No
MC-3299
MCL-1182
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Low
Chests seem to show Oak Plank particles when walked on and broken/hit. I know this happens because the old chest texture was removed, but it's as much of a bug as Squids surviving out of water, or a Wood Slab not burning.
Removing the whole old chest texture wasn't necessary. Since the chest particles were the top, re-adding only the top texture and repointing the particles to that tile would fix this.
Note: also affected 1.3.2, though that's not on the list of versions, and doesn't need to be anyway.
Chests seem to show Oak Plank particles when walked on and broken/hit. I know this happens because the old chest texture was removed, but it's as much of a bug as Squids surviving out of water, or a Wood Slab not burning.
Removing the whole old chest texture wasn't necessary. Since the chest particles were the top, re-adding only the top texture and repointing the particles to that tile would fix this.
Note: also affected 1.3.2, though that's not on the list of versions, and doesn't need to be anyway.
Chests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.
(Removing old versions affected is allowed when updating with new versions, right? As long as I don't remove the latest release?
will remove this line when answered)
Chests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.
(Removing old versions affected is allowed when updating with new versions, right? As long as I don't remove the latest release?
will remove this line when answered)Chests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.
(Removing old versions affected is allowed when updating with new versions, right? As long as I don't remove the latest release? I'll remove this line when this is answered.)
Chests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.
(Removing old versions affected is allowed when updating with new versions, right? As long as I don't remove the latest release? I'll remove this line when this is answered.)
Chests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.
Full list of blocks affected:
*Chest
*Trapped Chest
*Bed
*Workbench
*Bookshelf? (Should show shelf-face particles, not top/bottom, right?)
C
hests, beds, and some other wood blocks show particles of oak wood when you sprint on them, break them, etc. Chests do it because their terrain.png texture was removed in 1.3 (can't the chest textures be moved to the block textures folder anyway?), and beds do it because their bottom texture is wood.Full list of blocks affected:
*Chest
*Trapped Chest
*Bed
*Workbench
*Bookshelf? (Should show shelf-face particles, not top/bottom, right?)Certain wood-based blocks such as chests and beds generate oak wood plank particles when punched, run on, or fallen on, when these blocks all have textures on them more suitable for these particles. The following is a list of the known blocks affected:
*Chest (Beta chest textures were removed from terrain.png in 1.3.
*Trapped Chest
*Bed
*Workbench
*Bookshelf? (Should show shelf-face particles, not top/bottom, right?)
Certain wood-based blocks such as chests and beds generate oak wood plank particles when punched, run on, or fallen on, when these blocks all have textures on them more suitable for these particles. The following is a list of the known blocks affected:
*Chest (Beta chest textures were removed from terrain.png in 1.3.
*Trapped Chest
*Bed
*Workbench
*Bookshelf? (Should show shelf-face particles, not top/bottom, right?)Certain wood-based blocks such as chests and beds generate oak wood plank particles when punched, run on, or fallen on, when these blocks all have textures on them more suitable for these particles. The following is a list of the known blocks affected:
*Chest (Beta chest textures were removed from terrain.png in 1.3. It should be easy to add the chest textures to the new "blocks" texture folder and map the particles to that.)
*Trapped Chest (Added after removal of terrain.png, also has textures in a separate folder.)
*Bed (An oak wood texture is on the underside. The best particle would be the all-red half of the top.)
*Workbench (An ideal particle texture would be the top. Like beds, the underside is a plain oak texture.)
*Bookshelf? (Top and bottom are oak wood, sides are modified oak texture with the shelf added. Ideally, the particles would be from the sides.)Possibly not technically a bug, but other Issues not strictly "bugs" have been fixed for one reason or another.
Windows 7
Certain wood-based blocks such as chests and beds generate oak wood plank particles when punched, run on, or fallen on, when these blocks all have textures on them more suitable for these particles. The following is a list of the known blocks affected:
*Chest (Beta chest textures were removed from terrain.png in 1.3. It should be easy to add the chest textures to the new "blocks" texture folder and map the particles to that.)
*Trapped Chest (Added after removal of terrain.png, also has textures in a separate folder.)
*Bed (An oak wood texture is on the underside. The best particle would be the all-red half of the top.)
*Workbench (An ideal particle texture would be the top. Like beds, the underside is a plain oak texture.)
*Bookshelf? (Top and bottom are oak wood, sides are modified oak texture with the shelf added. Ideally, the particles would be from the sides.)Possibly not technically a bug, but other Issues not strictly "bugs" have been fixed for one reason or another.
EDIT: Seems to be caused by MC-1880 in that particles always come from the bottom of the block. (This has existed since Beta 1.7.2!) I would have added a possible solution to make the particles be from the side you click on, but that seemed more of a suggestion, and one that would be harder to code than simply remapping the particle texture. But since that's the intended behavior, then I guess that fix would make this suggestion moot aside from the chests, and that would be more of a suggestion to move the textures into the blocks folder.
Certain wood-based blocks such as chests and beds generate oak wood plank particles when punched, run on, or fallen on, when these blocks all have textures on them more suitable for these particles. The following is a list of the known blocks affected:
*Chest (Beta chest textures, which chests had used from Beta 1.8 to 1.2.5, were removed from terrain.png in 1.3. It should be easy to add the chest textures to the new "blocks" texture folder and map the particles to that.)
*Trapped Chest (Added after removal of terrain.png, also has textures in a separate folder.)
*Bed (An oak wood texture is on the underside. The best particle would be the all-red half of the top.)
*Workbench (An ideal particle texture would be the top. Like beds, the underside is a plain oak texture.)
*Bookshelf? (Top and bottom are oak wood, sides are modified oak texture with the shelf added. Ideally, the particles would be from the sides.)Possibly not technically a bug, but other Issues not strictly "bugs" have been fixed for one reason or another.
EDIT: Seems to be caused by MC-1880 in that particles always come from the bottom of the block. (This has existed since Beta 1.7.2!) I would have added a possible solution to make the particles be from the side you click on, but that seemed more of a suggestion, and one that would be harder to code than simply remapping the particle texture. But since that's the intended behavior, then I guess that fix would make this suggestion moot aside from the chests, and that would be more of a suggestion to move the textures into the blocks folder.
Chests and Bed (and other blocks) show OakPlank particlesCertain wood-based blocks give oak plank particles rather than their own texture
If I use /give to give myself a double-slab of any type (tried with all of them), they place as double Stone Slabs. This is technically a bug, even though you're not supposed to get double-slabs.
- DUPE - see comments -
First: Yes I used search.
The blocks 43:8-43:14 all say "Stone Slab" regardless of type. These aren't legitimately obtainable, but it's still a bug. (It would also help to note all the Block 43 data values as "Double XYZ Slab" or "XYZ Double-Slab," but I don't want this to be a feature request...
)
Also, 44:8-44:14 are bugged as well, and will always place upside-down and can't be combined into Block 43, not to mention the fact that they, similarly to 43, always say "Stone Slab."
First: Yes I used search.
The blocks 43:8-43:14 all say "Stone Slab" regardless of type. These aren't legitimately obtainable, but it's still a bug. (It would also help to note all the Block 43 data values as "Double XYZ Slab" or "XYZ Double-Slab," but I don't want this to be a feature request...)
Also, 44:8-44:14 are bugged as well, and will always place upside-down and can't be combined into Block 43, not to mention the fact that they, similarly to 43, always say "Stone Slab."
In-game spontaneous music may run a de-synced duplicate trackMultiple music at once
In the inventory, the entire potion has the "enchanted"gloweffectto it. When held in your hand, only the liquiddoes.
The hand-held version makes much more sense, since only the liquid is "special," not the bottle too.When seen in the inventory, or in storage (i.e. chests), the entire potion item has the "enchanted" shine effect. When held in your hand, however, only the liquid has the effect.
Either one could arguably be the better choice, but the bug here is the inconsistency.
Windows 7
Windows 7, Ubuntu 13.10, Java 7 Update 51
PotionsDon't Render RightPotions render differently in hand than in inventory/storage
There are a lot more "unnecessary" features in the game, and having to leave a horse, push it through the portal, and then go through after it and hope it didn't suffocate in the portal frame gets annoying.
When I updated to the snapshot for the first time to check it out, immediately I noticed a strange input lag. It takes a fraction of a second for moving the mouse to do anything to my viewing angle, and the same goes for moving with WASD.
To test it i quickly moved my mouse around the mousepad in short bursts, and there was a noticeable lag, even a gap between when I stop moving the mouse and when my viewing angle changes.
I
then went back to test in 1.8.8, and it worked perfectly, so it must be the snapshot.When I updated to the snapshot for the first time to check it out, immediately I noticed a strange input lag. It takes a fraction of a second for moving the mouse to do anything to my viewing angle, and the same goes for moving with WASD.
To test it i quickly moved my mouse around the mousepad in short bursts, and there was a noticeable lag, even a gap between when I stop moving the mouse and when my viewing angle changes.
It might not sound like much, but it makes the game unplayable.
I then went back to test in 1.8.8, and it worked perfectly, so it must be the snapshot specifically, and not just an issue on my end.
Roadsguy, its because Mojang (Searge in this case) said so. Does every bug report that gets resolved as intended need an explanation as to why said resolution was chosen?
@Roadsguy: Latest "legacy" driver is Catalyst 13.9: http://support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%207%20-%2064
Confirmed for
- 1.8.5 Roadsguy rather the normal expected behaviour: "Key combination cancel function of used keys"
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
Roadsguy Oval requested ownership, since they want to keep the ticket updated.
Yeah, I don't know what's up with this. :/
Adam is right, though. Paintings and Frames are entities, not blocks, so they "die" from explosions.
Diamond Spade? Are you using a mod or did you rename with the Anvil?
@Idea Guy: Give yourself block 44 with a damage value of 6. This will give you the single-slab version. Just place it twice.
Entity examples:
*Mobs
*Dropped items
*paintings, item frames
*shot arrows
*you (or at least other players in multiplayer)
*minecarts and boats
*Ender Crystals
Not sure why they're not blocks myself. Too complicated to code, perhaps?
It already checks graphically whether or not another chest is next to it. How do you think they connect?
Gone in 1.4.5 too.
Used search already, and didn't show anything related to this. One had something to do with the death screen, but wasn't this issue.
Same in 13w03a.
It's been several months. Is this works as intended, or just not seen yet by Mojang?
Slabs placing correctly, forming double-slabs, and being named properly, of course.
I figured that went without saying, but maybe not. Next time I'll actually fill out the form.
Oh, so that's how it works...
Did /giving yourself the double-slab versions of them in the past always put the top on all sides or is this new and permanent?
And technically you can get them in vanilla unless you don't consider /give vanilla despite the fact that it's not a mod or even an outside tool.
Just like BUDs, this was a useful bug used in lots of circuits since Comparitors were added. Now they broke half the circuits using Comparitors since 13w01a...
Well, if it lagged, then fixing it is good.
Will they still randomly update like Redstone Torches? Maybe make them update slower than before or something...
But come to think of it, won't using a clock instead for rapid-pulsing actually make it lag more, since there would then be six-ish Redstone blocks all updating simultaneously in a clock? Or would only one block rapid-updating cause the same lag?
Chad: Maybe, if you have space, add a pulse shortener to make it send a single short pulse? Will that make it shoot just once?
EDIT: It seems the bug was updating when idle. Do they still update when powered?
Do they still make constant updates when powered?
In the changelog for one of the snapshots, it said that 43:8 would now be the "smooth double-slab," and would stay so. I spawned the single-slab version to see what it was, and thought it was a bug. I do see why this is invalid, though.
Smart, you took a useless part that was mostly an oversight and re-added a removed feature that the community liked, also conveniently adding a new Sandstone block.
Now do the reverse with Locked Chests.
Forget this, I just want them to fix the ugly "horizontal line" that appears in the middle of right-side-up stairs caused by the texture orientation...
But anyway, you modded the game to fix this? Cool.
Oh really? Great!
Maybe I need to pay more attention.
Yeah, I thought it might have been reported before, but search gave me too vague results for the terms I could think of. :/
@Burger: Yeah, but then it would eliminate the problem of crafting too many, or not intending to craft any at all, or just changing your mind.
I got an email that the security was updated to Public. Wasn't it already?
Beds do it too, huh? Never really noticed that. I think I took more notice of it on chests because they removed the terrain.png chest texture.
The compass and clock are missing for me too.
Also, rename this to "compass and clock textures are missing," since that's more descriptive, and the potion rearrangement isn't a bug.
Sacheverell will seriously write "Different creative inventory" in the bugfix list even though that's so vague.
EDIT: Seems to be my texture pack. Default works fine. It also affects fire in my texture pack, but not in all cases, since some of it renders fine...?
@Adam: Late reply, but wouldn't it make more sense to just have them be Tile Entities?
Just wondering, do votes for an issue that's a dupe of another (such as
MC-10122) carry over to the original (like this one) when it's marked as duplicate?Affects 13w11a.
They finally fixed this, huh? It was so annoying.
And everyone thought it was intended.
@Jeb: Now that there's a new launcher...
BTW, is this really "intended," or is it just a won't-fix?
But it was reported during 1.4. You can't add previous versions as affected, which wouldn't have a point. :/
If they use a different texture when placed, why shouldn't they use the different texture in your hand?
Yeah, and texture pack makers can use this to make alternate chest styles.
Does doing /kill work with Resistance V? They could just make falling into the void have the same effect instead of gradually doing damage.
^This. /kill is supposed to, you know, kill you. Why should having a certain status effect make it not work?
Not the size, the pattern. The pattern in the placeholder is for the old horse saddle, not the regular one.
Look closer. See the little square thing on the top of the placeholder texture? That's not on the regular saddle. No item looks like that anymore, so why keep it that way?
It's only a missed thing that never got changed, not a suggestion. I see many reports of these that aren't just not resolved as Invalid, but are fixed by Mojang!
This can't be what the OP is talking about. What he probably means is that item frames always drop themselves and their contents as floating item entities when doTileDrops is set to false, even though destroying it normally drops nothing as intended.
No, it doesn't seem to. This is about the actual skin, that's about hitbox and worn block alignment issues.
I guess nobody saw my other comment?
Yes, it is. I get the bug in 1.6.2.
It was never intended for either effect.
Is this the bug where it says only Play Offline until you log out and then back in? The aforementioned bug was marked as a dupe of this, but this seems to be broader.
No, the head is supposed to be the head of the mob, yet it only shows one layer. For instance, if a zombie pigman head were made, it would be just the skull, like the baby version.
And BTW, if this is a suggestion, then all bug reports are "suggestions" as they suggest fixing the bugs.
How is this not a bug? The heads are supposed to render the head part of the skin. Why shouldn't it render the hat?
And why incomplete and not invalid?
Why not the other way around? The launcher is where you "craft" your session, I guess.
Oh, okay. I just think it's weird that they put in a feature (the player heads) that is literally only half useful.
Yeah, just noticed it myself in 1.6.2.
Why is this Incomplete?
No one else can download a file off your computer like that. You need to upload it to a file sharing site and add a link.
@Uknown Well, it's still a bug if it doesn't render the same way in different places.
@Zach: The background music looping is still there in 1.7.2. I just had it happen.
But... why, when all the other internal names are English?
I suggest making it so that commands run from inside tellraw simply are treated like command block/console commands. This would simultaneously fix the annoying problems of players not being able to click to run commands in tellraw if cheats are disabled, or if they're not an op on a server (it's not like they can get a tellraw message unless another op wants them to anyway...).
You need to name it exactly "jeb_" for it to work, including the underscore, as that is Jeb's in-game name.
It would be nice if it would work with simply "Jeb" without the underscore, but that's more of a suggestion than a bug report...
I'm betting PE simply lacks code for the hat layer. Either way, I don't see why this would be intended.
It's Hardcore mode in English. I guess there's no Spanish word for "hardcore?"
@Th3F4114n0n3: Notice how, on the right, the front texture has the right-side edge shading at what should be a cut-off edge. On the left, it just cuts off, with no edge shading.
Perhaps someone could just report it again and close this one?
What about confirmation that it's intended? The sound file still exists, and the sound had never played in multiplayer to begin with. No change was made to this in 1.3; it just took on the multiplayer behavior. So why would they "intentionally" only put it into singleplayer, and then make no note of removing it?
Works as Intended, but fixed in the next snapshot, and on the wiki changelog?
Wrong button, Mog?
Oh, well it was marked as having been fixed in the snapshot, and the wiki changelog also marked it as fixed (I suppose because of its fix version on here).
It still made more sense before. I mean it's iron bars, why's there a flat strip every block?
@Gary - That's not the point. Chests have their own texture that doesn't even look like recolored wood planks, so why should it break into the texture of wood planks? Same with beds. Even though beds have the wood texture on the bottom, it should show the red "blanket" particles because most of the block that's usually visible is that red color.
They made it so that minecarts' hitbox is two blocks tall now, so that they can be pushed off rails. That's the only practical application for this, and it not only breaks shooting from a minecart, but it also breaks some machines, like Etho's mob sorter. Bug or not, this should be fixed.
I would think this is a good feature if the minecart keeps its name data when placed, and drops itself as a named item when you break it, but if not, then it's got to be a bug.
This must be a similar issue to how you used to be able to pick block lit furnaces. I'll bet the glowing redstone ore item got removed with the rest of the technical block items, and pick blocking the glowing ore used to give you the glowing ore block, so now it doesn't give you anything. This should be a simple fix.
Well now that that's happened...
Affects 14w11b.
Just found this and decided to test it. I probably wouldn't have noticed it as my FPS usually isn't very good, but on low settings, there's no real difference in the animation between 1.4.2 slimes and 14w11b slimes.
Why on earth is this intended? Why shouldn't you be able to ride a horse through a portal?
Why on earth is this intended?
@Blah Yes, that's definitely the cause, but to have the hunger bar disappear in boats and minecarts with nothing taking their place is just silly, and makes it look like they missed a spot, intentional or a bug. A change resulting from another intentional change isn't necessarily intentional.
@Sen In that case, then there are a lot of bugs that shouldn't have been "fixed," but were, perhaps the first being "Squids can breathe air."
Oh wow, so it was already the side you click on before this bug was around? I would have added that to
MC-2614as an added request for a solution, but it sounded more like a suggestion that would be harder to implement than simply re-mapping the particle texture. But apparently it can't just be remapped.The hitbox was fixed in 1.7, right? Do worn blocks still float?
Perhaps he was trying to say that only the liquid should have the "glow?" I can't tell for sure. If that's the case, then it's a dupe of
MC-4660.@Pete: So it's like how the client thinks XP orbs can go over slabs, but the server doesn't, and you get "fake" XP orbs that repeatedly hop back to where they should be?
And yes, I knew the hitbox was fixed to that they're one block high. I was wondering if they had also fixed the issue with the worn blocks, which apparently they haven't.
@Steven: It's intended that even renamed mobs will despawn? That's part of this report.
It's fixed!
Now make efficiency work on glass/glowstone. ._.
@Preben - Why not? It worked before, and there's no better tool for it that does mine it faster. Why should you be limited to punching speed for two blocks when everything else is either one-hit destroy (e.g. torches) or is affected by Efficiency?
Which is exactly what's ridiculous here. ._.
@Preben: I'm not trying to suggest a feature, I was (both here and at MC-11992) asking why it's intended. Often when a report is marked as Intended like that, a Mojangster gives a reason. Here, it's an annoying change, with no obvious reason for it, yet clearly intended.
I guess I will be making a suggestion though...
Apparently this was fixed in 14w03a, regardless of it truly having been a bug or not. Should this be marked as "fixed?"
I agree with Dylan. Why is dirt on the list in the first place?
MC-32514is a similar issue. Both are odd oversights that would make sense to be changed, and were never announced as features.MC-32514has, I believe, been around since 1.3 added desert villages, and it was never changed or even mentioned until now, which really makes that seem like a feature suggestion. And yet this is a brand new thing, in a snapshot no less (which often are full of bugs), that was even demonstrated by Jeb. Other issues which are more nitpick/suggestion than bug have been fixed as well.I think we should get an official word on this before marking this as invalid/intended.
Well, now that we can do this, shouldn't this be marked as Fixed?
As FVbico said, there is an account called Herobrine, with Herobrine as the skin, of course. And I guess it really is a small world, because I know who it is that has the account!
The bug here is more likely that the dispenser needs a block below where the head would go to place it, but they're not supposed to shoot it out.
For just spitting an item out, always use a dropper. That's their intended purpose, and you never know what functionality may be given to dispensers for certain blocks/items.
Is it a Bukkit server?
So now both of these enchants work?
Possibly related, projectiles are thrown at weird angles when in double-F5 mode (facing backward). Not sure if this is intended.
Was this the cause of Etho's portal teleporting him thousands of blocks away in one of his recent LP episodes?
@Gerard – It wasn't "deleted by the internal servers." There was (and is) a bug where the sound would never play in multiplayer. With the server merge, it never plays at all. The merge had so many benefits that there's no reason to hate it. It was bad at first, but not now.
@Neil - You're saying it's fixed? I just tested it; it's not.
@J. P. - Source?
Why is this intended?
@Sonic - Or just make holding F3 cancel the directional buttons or something. F3 + S (reload sound) will also nudge you, for instance.
Still happens in 1.8.
Is the bug where you can't place blocks next to you if you're in the wrong position a part of this, and thus fixed?
EDIT: That is indeed fixed. Yay!
If it will be fixed in 1.9, shouldn't it be marked as Fixed now? Other bugs like this are marked as Fixed as opposed to Open.
"This issue is duplicated by..."
That's weird, my comment vanished. (I had asked "What are the NBT tags on each?") A renamed item stores its new name in the form of NBT, so it does have tags. The only thing I can think of that would make them not stack is if the tags are slightly different. No real way to find out except by opening up NBTexplorer and checking out your player.dat file for your inventory, as well as the block entity of the dropper.
Confirmed for 1.8.1.
Can confirm for 1.8.2-pre1, Windows 7, Java 8u25 x64.
So the hitbox issue was broken again for 1.8? Pretty sure that at least was fixed in 1.7...
The beta drivers don't seem to support the Mobility Radeon 4200 that I'm running, and adding -d64 didn't fix it. Am I out of luck? At it isn't completely game-breaking...
1.8.2-pre4 or will this really be put off to 1.8.3?
@Isaac
I meant something more along the lines of why glowstone/glass-type blocks don't have a pick set as their proper tool. It makes no sense that some blocks can't be mined any faster with any tool at all than by punching.
@Lawrence - Yes, that's how it works now, but just because that's the way it is doesn't mean that's intended. Besides, as Torabi said, it's even going to be fixed in 1.9, so it's a bit of a moot point.
I saw this bug in 15w31b, even in the overworld.
The bug seems to be fixed, but are they supposed to be backwards?
Still in 15w32c.
Fixed in 15w39a!
Actually, I remember from playing in 1.2.5 (and more recently seeing videos from before 1.3) that the travel.ogg sound played as you went through the portal (i.e. on the loading screen. I don't really remember how trigger.ogg played back then, it was never removed, and plays as soon as the player goes into the portal (not when they teleport).
Interestingly though, travel.ogg now plays after the teleportation loading screen. Before, it would play when the loading screen starts (with the "Entering the Nether" message).
15w44a confirmed.
Definitely very annoying, I've been working with command blocks and having the condition constantly reset every time I need to move/copy them is a huge pain.
How bad is the lag on small servers? I'll need to hold off on updating mine if it's too bad.
Can confirm for 1.9.2, also affects going from servers to singleplayer, and most likely singleplayer-to-singleplayer as well.
Confirmed for 1.9.2.
Yeah, fence gates, wall signs/torches, etc. shouldn't do this...
Can confirm for 1.9.4 and 1.10-pre1.
Additional information: it's only happened to me in my Ubuntu 16.04 installation when pushing the "Super" (Windows) key, which visually minimizes Minecraft and brings up Unity's search popup, but leaves an invisible Minecraft behind. F11 works as intended, as does quitting normally.
The way it works is that the window simply turns invisible. Keyboard action controls the stuff in the background, yet clicking only controls Minecraft, meaning that if you're careful you could blind-click your way to the title screen and quit. (I successfully tested this.) Another temporary fix is to do Ctrl+Alt+F2, from which you can run "killall -9 java" to kill all running Java, including the bugged-out Minecraft, and after which Ctrl+Alt+F7 returns you to your desktop. At least that's how it works in Unity; I haven't run any other desktop environments yet so I can't speak for any others.
I can confirm that in 16w42a it does still affect Skeleton and Wither Skeleton skulls.
I can confirm it for 16w43a.
Loaded a world, displayed a title for myself, quit immediately, and loaded another world. The title from the previous world showed up when I joined.
Confirmed for 19w14b.
The banners in my chest from before the name change from Illager Banner to Ominous Banner are also still named "block.minecraft.illager_banner" in 1.14pre5.
Confirmed for 1.14 Pre-Release 5. I just got a banner from a patrol captain which doesn't stack with the others, also from patrol captains.