Make WordPress Core

Opened 3 years ago

Closed 23 months ago

#23729 closed defect (bug) (worksforme)

Ticket #11289, IE bug fix: always pad the error page with enough characters

Reported by: wp4j Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: reporter-feedback close
Focuses: Cc:


Is it really such a good idea to put the padding where it is currently in the error pages? This causes all sorts of problems with Dom parsers... it should be placed somewhere after the html tag or better yet in the body... almost looks like someone is very proud of their fix and wants the world to see it lol

Change History (8)

#1 @dd32
3 years ago

for reference: [11340] - #8942
and later [12309] - #11289

#2 @SergeyBiryukov
3 years ago

Is it really such a good idea to put the padding where it is currently in the error pages?

Per ticket:11289:3, it should be where it is now. We could probably only print it if $is_IE though.

What problems does it cause?

#3 @SergeyBiryukov
3 years ago

  • Keywords reporter-feedback added

#4 @wp4j
3 years ago

What problems does it cause?

Will cause errors if output is being parsed by dom parsers. Basically breaks XML.

#5 @brokentone
2 years ago

  • Cc kenton.jacobsen@… added

#6 follow-up: @nacin
23 months ago

nginx's msie_padding directive ends up putting things below the <html>. Still not too sure why we care. I can get a parser to handle this OK. What am I missing?

#7 in reply to: ↑ 6 @rmccue
23 months ago

  • Keywords close added

As per the XML standard:

Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar.

Therefore, any parsers that can't parse this are violating the XML standard.

#8 @nacin
23 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Thanks for that, rmccue.

Note: See TracTickets for help on using tickets.