Nether portals place players two blocks beside the portal

Confirmed. Screenshot is taken after teleporting and just rotating but not moving.

It's not always 2 blocks, sometimes it's just one block. But it's always the same distance at the same portal.

Confirming this. Installed the pre3 build on my server and its putting players in the walls. Doesn't matter whether they're using the 1.8 client or the 1.8.1 pre3 client.

Building new portals didnt fix this.

I can confirm this too. And not only for players, but for all entities. I have a guardians farm that sends a bunch of guardians to the nether, 150-200 at a time. Now most of them spawn outside the farm and spread everywhere but where they used to go before the 1.8.1-pre3 update. I've encased the destination portal in solid blocks to prevent them from spreading everywhere, but now most of them just die inside the surrounding walls.

I haven't tested thoroughly, but it seems that this problem only affects north-south portals, east-west portals seem to work fine. I'll do some more testing to confirm.

Edit: In the attached screenshot, the portal is oriented north-south, which seems to confirm this a bit more.

Edit 2: Finally, orientation of the portal doesn't make a difference. Reverted server to 1.8.1-pre2 because players keep dying inside walls!

Copied this over from MC-793 since this seems to be the right place.

This bug is now present in 1.8-pre3 since dinnerbone fixed MC-3. I tested my portal created in a snapshot prior to the 1.8 release, and I now take damage after I get to the nether, depending on which of the two blocks I stand in when entering from the overworld.

Things to note: Prior to the fix for MC-3 when entering the other dimension when using a portal, you would still be in the portal, now you are no longer in the portal. I believe that this is the source of the damage bug as the player placement is now outside the portal and sometimes this might be inside a block. This could be fatal for the first trip to the nether if you're over lava so I really hope this bug gets escalated!

Both portals are facing north-south. When I enter the overworld portal standing on the left side while facing south, I exit the nether portal on the left side but one block over and forward, facing north. If I enter the overworld portal standing on the right side while facing south, I exit the nether on the left side, but TWO blocks over and forward, which for this portal was a wall so I took damage. My portals are the traditional size of 5 tall by 4 wide with the interior of the portal being 3 tall by 2 wide.

--and--

And here is some more information - One of my portals in the nether had the four blocks immediately in front of the portal (at the same level as you would be standing on the obsidian of the portal floor) filled with a half slab, which means before this breakage, you would exit the portal and then rise up a half slab height. After the bug was introduced, you now go somewhere else, which in my case is below the portal and into the lava pool underneath 😞

One more thing (I hope): While I was testing my nether portals I noticed a possibly related problem. For some reason the portal linkage would get scrambled sometimes. I have multiple portals that are multiple chunks apart in the nether (and in the overworld of course) and for some reason when leaving one of them in the overworld it would redirect me to the wrong portal in the nether even though the correct gate was at least 500 blocks away.

Related to this was going through the nether portal and ending up "stuck" in the overworld, with the F3 key showing my location as being at the previous overworld location I had been testing, but the world refusing to render. After playing with the chunk rendering distance I was able to see that I was in the correct location (not according to F3) but was stuck in something and the chunks nearest me would not load.

I think that MC-3 doesn't relate to this. MC-3 is talking about orientations, and this bug is talking about teleports off-sets.
MC-3 was fixed in Pre1, and this didn't showed till Pre3.

Hope this gets fixed, because, if above lava, YOU WILL FALL TO YOUR FIERY DOOM!

Bah. I tried to search for this, but the title didn't match because I put a space in 'nether portal'. Ah well. Sorry about the dupe.

What I noticed is that the placement position depends on the size of the portal. With the "traditional" 2-wide portal it places you 2 blocks to the left (in my case), but if you have a 18-wide portal (20 wide with the frame), it places you 18 blocks to the left from the left end of the portal.

@jenn try it with a new portal, as the old portals may still be affected, just like the old portals before they broke were not affected.

Bob Dobbs,

It affects all portals. Old ones and new ones. They're all broken, and very dangerous. They make you spawn in solid blocks, or in mid-air over a lava lake. Stick to 1.8, or 1.8.1-pre2. You can use the pre3 or pre4 client on 1.8 servers, but the server itself cannot run pre3 or pre4.

Jens Pott (or mod): can you update the "affects version/s" detail info to show 1.8.1-pre4 too?

ummmmm....no, it doesn't affect all portals.
Anyway, all you have to do is jump and you pop up out of the ground if it did catch you.

To say that one only needs to jump and pop out of the ground is definitely an inaccurate description of this. While Bob Dobbs may have been fortunate enough to be in that situation, on the server I administer, where we have a network of tunnels near the roof of the Nether for transportation, this bug has resulted in player deaths due to falling damage (due to players being spawned in air blocks beneath the tunnel floor) and suffocation (due to players being spawned into solid blocks, in some cases the obsidian blocks of the portal frame itself).

I have tested the effects of this bug thoroughly, and it is not completely consistent, but in the majority of cases, I found myself getting spawned in to solid blocks and taking suffocation damage where the only way to free myself was to attempt to Ender pearl myself out of the wall or dig myself out – jumping out rarely works. The temporary fix so far has been to dig out extra room around portals where players typically would spawn due to this bug. In my testing, the bug applies to portals constructed before and after the 1.8.1 pre-releases.

Yes it does affect all portals. New ones, old ones just the same. We also use a tunnel network near the top of the nether, and the greatest problem are people suffocating in the walls because of the portal exit displacement.

I have not had this problem as of yet,
My problem is the portal spawning in mid air right over the lava ocean with nothing to step out on.
Sometimes I do get like maybe 10 blocks of netherack on one side to step out on, but that is also floating over the lava to where I have to build a bridge to reach the biome areas

Here it a file of what My portal I spawned in , it is inside a cobble house now, Spawned in midair with no netherack attached between 2 shear drops about 23 blocks above lava ocean.

I made multiple portals on different servers yesterday with no problem, where I did see it in pre3. I do know it did exist.
It doesn't now.

Bob: I did that too in a couple of different worlds. The bug seems very inconsistent. My 1st attempt made me spawn 1 block in the ground, 1 block away from the portal... But as the ground was only 1 block thick, I fell into lava below. The next 8 tests still made me spawn away from the portal, into the ground, but I was safe because I had a solid block under me. The 10th attempt made me spawn right into the portal frame, I freed myself, only to fall 35 blocks to my death.

The fact is, when you go through a portal, you should always spawn inside the portal frame, no matter what. That NEVER happens. It's always at least 1 or 2 blocks offset, outside the portal frame.

If a mod could add a space in "Netherportals" to make it "Nether portals" that would be much appreciated, it seems that there are a lot of duplicates recently due to this spelling error :/.

Updated, but 99.999% of duplicates are due to no searching in the first place...

Thanks anyway.

Thank god i'm not the only one seeing this. I'm locked on pre2 right now though 😞

Have you tried to fixed this issue in 1.8.1-pre5? It seems to work ALMOST properly now. See more below

I spawned 1 block in front and below the portal. But the size of the portal now doesn't matter. I wouldn't say it's fixed, but it seems to be better and more reliable.

Confirming Jens.

Always spawning one block in front of portal right now, not sure if one block down due to all the portals I tested having the obsidian for the bottom of the portal one block above ground.

Yes, that's true. Jens and Kevin are right – better but not solved.

As long as you don't respawn INSIDE the portal frame, I'll consider them broken. You never know what that block in front of the portal is gonna be. It could be a lava block, it could be an air block with a 50 block drop. The portal will not place you on the nearest safe block, it will place you on that block, no matter what it is. Dangerous and unreliable.

Looks like it is fixed, so you don't spawn above lava. Though, still a problem, if a player sealed a nether portal, you may have a chance of either being trapped in a portal, or get dumped in lava.

Bug still exists in 1.8.1.

Oddly, its fixed for me in 1.8.1.

It is not fixed. Going through a portal still places you outside the portal frame at the destination. If there are no blocks there, you fall to whatever lies beneath. Unreliable and unsafe. Why would the game place you on an air block in the first place? You should ALWAYS spawn INSIDE the portal frame, no matter the conditions. You go through a portal, and at the destination you have an obsidian block under your feet. Simple and safe. That has always been the case until 1.8.1-pre3.

I just saw Dinnerbone was assigned to the case, so my hopes went high again! But I feel 1.8.1 was released too quickly and feels kinda botched. 1.8.1 should have been a pre-6 snapshot with a showstopper bug like this one. Especially when considering that most bugfixes were purely cosmetics, nbt tag stuff, and spectator mode glitches. It's almost as if my car had no more brakes and a big radiator leak, went to the garage, and the mechanic only repaired a tiny scratch on the paint and changed the carpet inside the trunk!

(Vanilla Server 1.8.1) I had a portal spawn on a 1 block thick ledge over lava. It seems I spawned in before world generation completed and materialized below the ledge falling to my death. When I went back through the portal, I materialized in front of the portal instead of inside the portal.

Ray Yates: Revert your server to 1.8.1-pre2 (or plain 1.8) to fix the issue. I had to do the same. You can keep the 1.8.1 client release without any problems, unless you also play in singleplayer, in which case, you should also downgrade your client to 1.8.1-pre2.

Confirmed for:
-1.8.2-pre4 Offset is now 1 block

Still exists in 1.8.2-pre5, offset is 1 block.

Still exists in 1.8.2-pre6, offset is 1 block.

What I understand, the portal tries to place you 1 block to the front and 1 block under. If there's a half slab, sometimes (rarely) it places you to the bottom of the block under the half slab. See Attached screenshot 2015-02-02_22.27.08.png

In 1.8.2 you now spawn in front of the portal, but not one block below. It's getting better but it's not as it used to be...

Thanks for the info Jens.

In the interim I modified all my portals to have stairs leading up to them and have several blocks in all directions clear, with a floor.

Took a lot of work, but I don't want future variants of this resulting in unhappy kids in my house 🙂

Still present in 1.8.3

Thanks Piper.

Please keep any discussion on the Minecraft Forums, or Reddit.

@ [Mod] CubeTheThird

As per Mojang's instruction, tip#4, this area is also for discussion: https://bugs.mojang.com/browse/MC
I've searched and have yet to find a posted list of rules, whereby if broken a 'mod' is permitted to delete clients comments for reasons which are not listed whatsoever. So since the only official mention of comments is that they are allowed, I seriously question you have the authority to create your own rules, change policy on behald of Mojang, and delete that which you don't agree with.

Deleting our discussion because we are complaining about Mojang not fixing the bug at hand is unacceptable and extremely unprofessional. The proper response by a professional organization that cared about its clients would be to issue a response/explanation/apology. By you deleting our comments which are intended to underline the importance to us of desired resolution, how is anyone at Mojang to notice and take seriously? You have in effect increased our frustration, and taken it upon yourself to judge the validity of our discussion. If a 'mod' is not happy with said complaints, then there should be a mechanism in place for the mod to pass them along to Mojang management to address. I posed some very valid questions about the bug resolution process, but you deleted instead of attempting an answer. Please provide contact information for Mojang's complaint department, not a third party website or a forum.

Regrettably you are likely a volunteer, but you shall certainly be reported nonetheless and hopefully then can be trained in some aspects of professional cutomer service. Also you should consider the public optics of a company deleting client comments instead of addressing them.

(Note comment deleted because it was posted twice).

@Joseph Charron

I am sorry you feel frustrated, and it is perfectly understandable, as this (like other bugs) which can affect gameplay have yet to be fix by the dev team. I am also sorry that you feel the removal of posts regarding complains is unprofessional, but please keep in mind that this website is intended to function solely as a bug tracker. Indeed the 4th tip listed on the main page mentions discussion, but we expect this to be relevant and productive to the bug tracking environment. It's for that very reason the subreddit aforementioned was created, so that off-topic and general discussion could be conducted. I understand that the expectation is, by commenting on this report, it will encourage the developers to correct the issue, but this is not generally the case. Another thing to consider, is that the issue may be fairly complex to resolve, and will take time before a fix is released.
I also ask that you respect the volunteers who moderate this tracker. Please keep in mind though, that we are not here to provide customer service. Again, this is a bug tracker, and not a technical support forum.

We do like to have comments contributing to the bug reports, such as updates on it's status, additional information about the problem, or suggestions on what the underlying cause of the problem is, and what can be done to fix it. It is advantageous that Mojang allows community involvement in bug reporting, but this also comes with the downside of a very active bug tracker, meaning more work to sort through the information, not to mention more issues being identified, regardless on how severe or minor they are.

So I decompiled the code for 1.8.3 class "adv", which is what handles portal travel.

In the code for placing the player there's a bit like this, which seems to be for adjusting the X/Z position from the corner portal-block of the destination portal to more closely match where the entity entered the source portal. var31 is X, var33 is Z.

adv.java

if(var16.b().k() == cr.a.a) {
            var31 += (double)var16.b().g(); // !!!
            var33 = var18 + (1.0D - var1.aG().a) * (double)var16.d() * (double)var16.b().e().c().a();
         } else {
            var31 = var18 + (1.0D - var1.aG().a) * (double)var16.d() * (double)var16.b().e().c().a();
            var33 += (double)var16.b().i(); // !!!
         }

The lines I've commented with "!!!" are the problem, they move the entity 1 block in the "facing" direction of the portal without bothering to check for ground underneath, blocks in the way, or anything else. Modding the class to remove those two lines restores the expected behavior of spawning within the destination portal itself.

Anomie X:
This is an amazing find, hats off!

Mods:
Please forward this fix to Mojang. The simplicity of the fix, and the fact that it comes from someone in the community stands as a good potential proof that Mojang never even looked into that deadly bug in 6 months. I'm at the point where I'm about to submit a new entry: "MC-XXXXX - Bug Tracker not working". 😃

And now for the comment-deleting stuff, I agree with Joseph Charron that it is very unprofessional, and rude. I understand it could get messy (look at the subreddit, it's so messy we can't find anything in there). But I think opinions count, as it reflects how we feel about a product we paid for, and how we expect Mojang to acknowledge that by actually fixing stuff that REALLY requires fixing. This bug is frustratingly KILLING us, spectator-mode glitches aren't. - Comment deleted? -

@Anomie X

But moving the player one block forward isn't the only problem. Sometimes they are put several blocks below the portal. Is that a separate bug then?

@KingSupernova: Wasn't the spawning too low part fixed in 1.8.1-pre5?

Oh, was it? I didn't know.

Yes it was. The moving forward one block is the only issue now. By the code, I think the second part of the bug was intended originally but there is the obvious problem that the code doesn't check for a drop or a wall in the new location. The reason this bug is taking so long is that the devs might want to keep the 'spawning one block in front of portal' feature while checking for drops and walls and this is more difficult than removing two lines of code.

Why doesn't it just spawn the player in the portal like it used to? It seems like the simplest solution, and it also makes the most sense from a flavor perspective.

I agree with that, I'm just saying that the devs might be trying to do a more complex solution than removing two lines of code.

IMHO they need to quit assassinating peoples players/HC games, roll it back like it was, Spawning inside the portal !
Then they should play with their code on a closed private server (with massive testing) till they get it right ! -Then maybe put it in ! OR NOT !
As you can see by my 006 pic above (attached to NOTHING) it is no fun dropping 30+ blocks into an ocean of lava to die and lose all your inventory !
I resorted to potions to get back up there and build the office around it when I discovered I was only about 120+ blocks away from a nether castle !
I have a few portals filled with blocks of coal that I avoid using due to this issue ! So far I had only spawned in the blocks below the portals once. (guess that was fixed shortly thereafter)

I've resorted to screenshotting my inv before entering a new nether portal so not too much damage is done. This glitch breaks hc though. Can't they just patch it with the above fix-remove 2 lines of code? Then they can try adding a more reliable offset system after the patch!

@unknown spent a fair amount of time fiddling with the nether portal logic over the course of the recent releases and pre-releases. I don't think he's happy with the current implementation, but didn't want to spend more time fiddling with it, when some of the other things he wants to change with nether portals will require much more substantial changes to the code. Hacky fixes tend to be unsatisfying for a developer, particularly when you keep piling them on, knowing you're just going to have to rip the whole mess out and rewrite it from scratch.

The thing is, most of the time the current implementation isn't a problem. The portal will usually spawn either completely over solid ground, or will spawn an obsidian platform, so placing the player next to the portal without checking for solid ground isn't a problem. It's possible to remove those ground blocks afterward, but that may be an intentional feature to allow players to make traps or assist in moving mobs between dimensions. The corner case, where the portal spawning algorithm incorrectly identifies a location as not requiring an obsidian platform, is rare, but incredibly frustrating, and absolutely awful on hardcore mode. What would be helpful are exact examples of seeds and coordinates where it does this, so the developers can easily experience it for themselves. That would be more helpful in getting this changed than angry, demanding comments. Anger doesn't engender sympathy – it makes people defensive.

I agree that, in general, companies should not attempt to sanitize or distort discussion of their products, particularly in a place that they have provided for that discussion, both as a matter of principle, and as a matter of self-interest. However, this is a bug tracker – not a complaints department, not customer service, not technical support, not a help desk, and not a forum for the general discussion of Mojang's products. It's purpose is to efficiently track information about bugs in their software, including descriptions, reproduction steps, causes, examples, and potential fixes. Our responsibilities, as moderators, are to condense and organize that information so as to make it easier for the developers to find, so they can use their time more efficiently, and thus fix more bugs. Spurious tickets, comments that include opinions, rather than facts, and irrelevant discussion make it harder for the developers to find the relevant information on the tracker, and thus make them less efficient at fixing bugs. The tracker is a firehose, and it's our job to reduce that torrent to something manageable, without losing any relevant, important information.

There are other, more appropriate places for communicating with the developers to let them know how you feel. They can be reached, directly, on places such as twitter, reddit, irc, etc. Mojang is a small company, and has no need for an official complaints department, which would only serve to depersonalize their relationship with their customers. They don't run their business like most other companies, preferring a much more informal approach that involves the community, rather than keeping them at arm's length. The moderators on the bug tracker are all volunteers, but we're in direct contact with several of the developers, and confer with them on how they want the tracker to be run, or bring issues to their attention. You're welcome to voice your opinions to them, but they're unlikely to see them if you do it here. They can look through the history of the tracker and see everything, including our actions and any comments that have been edited or deleted, whether by a moderator or a regular user. So we're not hiding anything from them. But the sheer amount of data on the tracker makes it unlikely that they'll see any particular comment or issue that someone doesn't bring to their attention.

Sorry to clutter this further, but - I very much doubt the very original behaviour was 'expected' - as after travelling through a portal, one would in short order be teleported back as one had been ported into a portal square. Also my apologies if it seems a hair out of the flow, but I accidentally failed to post this the other night, and tried to restore it to the current context.
Expected behaviour from portals in other games is that they port one to a destination upon entry (and typically must be re-entered in order to trigger that), or - they port one to a destination very near to another portal, rather than in it.
The current issue, which I do agree is quite serious, is not fixed by merely unrolling the last change; the last change was very likely an attempt to produce expected behaviour.
The previous code mostly worked as the player needed to be quite 'into' the portal tile to trigger it, and the portal generation would clear the volume in directly in front of the portal, produce a little lip if needed, etc... the current code does not create enough of a lip, nor clear enough volume, on portal generation to account for the new player location chosen, and it makes no attempt to deal with grandfathered tight-fitting portals from old worlds.
unrolling the change might be a quick fix - but part of the delay might well be a significant rewrite of the portal code, other nearby issues which aren't public, etc... and how that got scheduled with all the other important work is not my place to guess.
Still - if it isn't dependent on much else - my guess is that there is a safe place to port the player to: namingly the centre of the block directly in front of the portal block chosen, as that will be both cleared and floored by current portalgen, if needed, and also puts the player out of the portal itself. This location was likely the intent of the last change, but it was overshot by some amount. Also - as is clear from gzurti's attachments, the last change was larger and would drop the player well away from the portal in some edge cases.
In short, we don't know the extent of the previous changes, nor the full set of issues they were attempting to resolve.
Suppose this is related to the falling damage issue. My impression was that it used to be that with a just-generated portal - they would port the player to the nearest portal block within certain constraint. But this is hairy - from below this might be a block at ground level, and from above this would be a block with the player's head in the obsidian, or alternately, it might be a block at head level, but from the other side a block with the player's feet in the rock. combined with falling damage for simply porting so the player's head touched the top of the portal - fixup was needed already. add in the 'last portal used won't resend hack' and it's getting ugly. If an attempt was made to clean up the behaviour such that portals could be created that did not require the same obsidian shell, then it would start getting weird fast.
However it seems clear given the tests we have at hand, that the two expression change to the code suggested by removing the addition of those values from the player position, is not sufficient to fix all the cases where players are currently ported to odd and lethal locations. Also presumably it is not sufficient to fix whatever issue that addition fixed (say, the falling damage?).

Torabi beat me to the punch with the reminder I agree with so strongly: the best way for us to help from here, without knowing the full suite of tests and constraints the portals need to adhere to, is to identify apparent odd behaviour and try to help replicate it by finding seeds, short descriptions, and screenshots that make it easy for the devs to confirm unexpected behaviour and test potential fixes.
peace and lucks, dfj.

I very much doubt the very original behaviour was 'expected' - as after travelling through a portal, one would in short order be teleported back as one had been ported into a portal square.

This is not the case in 1.8 (i.e. before this bug was introduced), and very likely is not the case in 1.8.3 either. The post-teleportation "cooldown" timer is reset any time it hasn't expired and the entity is within a portal. For players this timer is only half a second, so stepping out and immediately back in is usually enough to let it expire.

Much of the rest of your wall of text is based on this faulty premise.

The current issue, which I do agree is quite serious, is not fixed by merely unrolling the last change

Yes it would be. Only your imagined "expected" behavior would not be fixed.

my guess is that there is a safe place to port the player to: namingly the centre of the block directly in front of the portal block chosen, as that will be both cleared and floored by current portalgen

Also false. That block isn't cleared except in the last-resort case where the game couldn't find any valid location to place a portal. Nor would it be the case for built portals, for example many of mine are against a wall.

Important:
As far as whether the proposed removal of those two offsets restores original pre-1.8 behaviour, I no longer have an opinion, as I didn't realize the distance of the offset had been limited to one due to having missed a few remarks in the history. My bad - though I blame unfamiliarity with jira. 😛

Less helpful to the bug, but still relevant:

– I very much doubt the very original behaviour was 'expected'...
I'm sorry I didn't spend more lines explaining this so it was more obvious - I was referring to releases prior to 1.8, though I'm not clear when the timer kicked in fully. We certainly used to get teleported back if we dawdled in the portal. 'Expected' is in quotes because it is very hard to pin down any sort of objective notion of what different players will find intuitive.

– That block isn't cleared except in the last-resort case where the game couldn't find any valid location to place a portal. Nor would it be the case for built portals

two things:
1) If the portal generation code is not creating portals safely enough given the intent to have the nether be dangeous - then that is presumably unexpected behaviour, given dinnerbone's comments and changes as above. If the new intended behaviour is to place players in front of the portal, then the issue is now with the portal generation code not finding reasonable places to generate, clear enough space, or build additional floor.

2) I don't think built portals matter much - if the behaviour of portals is known to teleport players +/-1 block in the direction the portal is facing, then players will build portals such that this is good. Bringing portals from previous versions forward really happens, but - outside of portals in front of walls now being verbotten, reasonably built portals should not be dropping people through the floor now.

Finally:
I support stopping teleporting players into the portal square, as it frees up portal mechanics to allow other shapes and sizes of portal, ideally supporting teleporting into borderless portals, portals with target destinations in their extra info etc... or even other fancier portal dynamic patterns (different moduli, worlds, near portal finding, etc...

I'm going to be shooting for seed + replication script from here on in. Thanks for your patience.

For 1.8.4 this will be fixed just by keeping the player in the portal block, but this is not ideal and it should make sure we can place them outside if it's a "preferable" spot (ie: not a drop into lava). This will be fixed fully in a later release.

That's great! No more falling into lava!

I would have thought that having a player be teleported to a portal block is always the safest place to be as lava and water cannot flow into them. If someone pours lava on top of or all around the outside of a portal, there will be no safe place to teleport a player to other than inside the portal.

Safest, yes, but maybe not the most desired when that isn't the case.

Presumably the future fix will be something along the lines of checking for any liquid or any solid blocks intersecting where the player would be placed outside of the portal plus ensuring there are solid blocks just under where the player would be placed. If the check fails (maybe try it on both sides of the portal just in case?) then it would have to fall back to the current behavior.

Then be ready to respond to bug reports in case there's any bugs like certain non-solid blocks accidentally being considered solid. 😉

Yes it needs to check for lava flowing around the portal !
I have one instance where the portal appeared in a lava flow going past both sides of it !
If it were not for appearing inside the portal, I would have roasted !
The one instance I really liked was a portal was created with a cobble base on both sides and was set on top of the netherrack !
I have never had that happen since - I believe that was in version 1.8.1.

Added photo of nether portal - had lava flowing around both sides - Luckily spawned inside portal - cleared one side to get out an stop lava flow - I believe this was in version 1.8.1
Something to consider in fixes.

Thank you a ton Dinnerbone for fixing this for us! 🙂

Good example Alpha Wolf. Even if the code that chooses where to spawn you checks for lava and does not place you in it, there could be lava source blocks close by that have not started flowing yet. As soon as you spawn it, the lava flows into the block that the game has placed you on and you burn up.

From what I have read in the comments, I assume people believe that the reason for change to spawning outside of the portal is to stop people looping back and forth repeatedly between the nether and the overworld if they do not move.

Personally, I find looping more desirable than burning in lava.