Potion of invisibility doesn't prevent mobs from attacking a player

can confirm bug exists in 15w39c on OSX 10.10 java 1.8

I think this is intended? I mean sure it makes no sense why it would be but it just is, I could be wrong though.

still present in 15w42a

I believe intended behavior is for provoked mobs to track you as normal, the being able to see you regardless of potion effect seems like the bug portion of this report.

Confirmed for 16w04a

Looks like Magma Cubes are not ignored anymore in 1.10-pre1. Can anyone confirm?

No, it's still the same.

still in 16w43a

still in 16w44a

still in 1.11 Pre-Release 1

Tested in survival with no armor

AI behavior the same with or with out invisibility potion (ie potion has no affect):

Guardian, Elder Guardian, Blaze, Ghast, Wither, Rabbit, Ocelot

Did not test with all hostile/neutral mobs, but those I did worked until hit with the exception of Magna Cub/Slime - they seemed to still not see me.

Still in 1.11.2

Still in snapshot 17w06a

Was already marked as affected...

i spawned some guardians and changed my game mode after slipping an invisibility potion but they still shot lasers at me

That's what happens when you add a feature without proper testing if it affects other things. Its when they changed player detection mechanics related with introduction of the feature where wearing certain skulls decreases detection range for certain mobs (e.g. wearing zombie, creeper and skeleton heads). Some pieces of code got moved where it shouldn't be and now player detection is kinda broken (i.e. guardians would also detect you through sugarcane, and they shouldn't, according to 1.8) (check mob targeting functions in all the subclasses of mobs).
If there was a test to make sure previous mechanics work, it wouldn't be released in this shape.

The reason for this behaviour is that in 1.9 the check for invisibility has been moved from entity.ai.EntityAINearestAttackableTarget to world.World.select_closest_player_to_attack or something like that and placed code that handles wearing skulls and their effect on the detection distance in this place.
The target selection (based on the supplied predicates is called in three if-else clauses in EntityAINearestAttackableTarget.shouldExecute()

IF random THEN fail
   ELIF target != EntityPlayer THEN world.getEntitiesWithinAABB(...) // no checks for anything, as long as the selector predicates apply
      ELSE (target=EntityPlayer) THEN world.getNearestAttackablePlayer(...) //does check for various aspects including invisibilty

This code works fine IF the class of entities to target is specified as Player, and many mobs has it this way even having many adversaries:

Zombie:

protected void applyEntityAI()
    {
        this.tasks.addTask(6, new EntityAIMoveThroughVillage(this, 1.0D, false));
        this.targetTasks.addTask(1, new EntityAIHurtByTarget(this, true, new Class[] {EntityPigZombie.class}));
        this.targetTasks.addTask(2, new EntityAINearestAttackableTarget(this, EntityPlayer.class, true));
        this.targetTasks.addTask(3, new EntityAINearestAttackableTarget(this, EntityVillager.class, false));
        this.targetTasks.addTask(3, new EntityAINearestAttackableTarget(this, EntityIronGolem.class, true));
    }

However Guardian doesn't have it specified as EntityPlayer.class but rather as a custom predicate:

this.targetTasks.addTask(1, new EntityAINearestAttackableTarget(this, EntityLivingBase.class, 10, true, false, new EntityGuardian.GuardianTargetSelector(this)));
...
    static class GuardianTargetSelector implements Predicate<EntityLivingBase>
    {
...
        public boolean apply(@Nullable EntityLivingBase p_apply_1_)
        {
            return (p_apply_1_ instanceof EntityPlayer || p_apply_1_ instanceof EntitySquid) && p_apply_1_.getDistanceSqToEntity(this.parentEntity) > 9.0D;
        }
    }

replacing single AI task with two calls, like with Zombies, would be a quick fix but removes the ability for players to avoid guardian attacks hiding within a flock of squids. The proper fix involves reorganizing the shouldExecute() function so it checks properly for things that getNearestAttackablePlayer does:

/**
      * Returns whether the EntityAIBase should begin execution.
      */
Add a comment to this line
     public boolean shouldExecute()
     {
         if (this.targetChance > 0 && this.taskOwner.getRNG().nextInt(this.targetChance) != 0)
         {
             return false;
         }
         else if (this.targetClass != EntityPlayer.class && this.targetClass != EntityPlayerMP.class)
         {
             List<T> list = this.taskOwner.world.<T>getEntitiesWithinAABB(this.targetClass, this.getTargetableArea(this.getTargetDistance()), this.targetEntitySelector);
 
             if (list.isEmpty())
             {
                 return false;
             }
             else
             {
                 Collections.sort(list, this.theNearestAttackableTargetSorter);
-                this.targetEntity = list.get(0);
-                return true;
+               if (!((list.get(0) instanceof EntityPlayer)))
+               {
+                    this.targetEntity = list.get(0);
+                    return true;
+               }
             }
         }
-        else
-        {
+       //CM removed condition - if previous block executes it always exists unless its a player that got selected
             this.targetEntity = (T)this.taskOwner.world.getNearestAttackablePlayer(this.taskOwner.posX, this.taskOwner.posY + (double)this.taskOwner.getEyeHeight(), this.taskOwner.posZ, this.getTargetDistance(), this.getTargetDistance(), new Function<EntityPlayer, Double>()
             {
                 @Nullable
                 public Double apply(@Nullable EntityPlayer p_apply_1_)
                 {
                     ItemStack itemstack = p_apply_1_.getItemStackFromSlot(EntityEquipmentSlot.HEAD);
 
                     if (itemstack.getItem() == Items.SKULL)
                     {
                         int i = itemstack.getItemDamage();
                         boolean flag = EntityAINearestAttackableTarget.this.taskOwner instanceof EntitySkeleton && i == 0;
                         boolean flag1 = EntityAINearestAttackableTarget.this.taskOwner instanceof EntityZombie && i == 2;
                         boolean flag2 = EntityAINearestAttackableTarget.this.taskOwner instanceof EntityCreeper && i == 4;
 
                         if (flag || flag1 || flag2)
                         {
                             return 0.5D;
                         }
                     }
 
                     return 1.0D;
                 }
             }, (Predicate<EntityPlayer>)this.targetEntitySelector);
             return this.targetEntity != null;
-        }
+        //  removed condition
     }

This allows for AI tasks that does call for a broader class than EntityPlayer, use proper player target selection method if a player got selected across all specified mobs.

Othe approach that can be taken would be to put all the universal checks for detection radius for all targets (like wearing a skull, or having invisibility) in one place and check it for all targets. It would be a better approach because then invisibility potions or wearing skulls would work on other entities as well (i.e. villager wearing zombie skulll will be less prone to attract zombies, or golems will not target invisible Zombies), which is not the case currently.

I tested with other mobs listed in this bug report and they were not affected by this bug from my testing. However organizing better the target selection code would help solve these unknown cases and prevent problems in the future.

Still present in 1.13-pre6

Confirmed for 1.13

Confirmed 1.13.1

Bug still in 1.13.2 and 19w02a

Still happens in 19w08b, but the guardians will not target invisible players unlike other mobs when attacked.

Also, zombies and their variants will permanently be able too see you from a normal range if you hit them. This is different from non-zombie mobs because other mobs detect the invisible player at the expected distance after losing sight, but zombies will continue to be able to see you as if you weren't invisible. (Same glitch applies to zombie pigmen, husks, and drowned.)

Still happens in 19w09a

Can confirm this is still happening in latest release. 

Confirmed for 19w46b.

The "provoked" behaviour listed in the report is intended.

Should also add to the unprovoked, shulkers because as soon as you get near them they start attacking with invisibilty still present in 1.15.1

Also affected by hoglins in 1.16 snapshots.

Hoglins are covered by MC-172479.

I think the bug has been fixed at some point.

It is intentional that mobs can sometimes see invisible players up to a distance of 3.5 metres (or even further if the player is wearing armor).

It is intentional that mobs (except slimes) who are attacked by invisible players can see their attacker and fight back.

Many players thinking a return of MC-89309

I think remaining issues with invisibility should have their own reports.