Skip to main content

Bug Tracker

Side navigation

#10198 closed feature (migrated)

Opened September 03, 2011 02:51PM UTC

Closed October 20, 2014 11:34PM UTC

Run jQuery unit tests in XHTML

Reported by: dmethvin Owned by:
Priority: high Milestone: 1.next/2.next
Component: build Version: 1.6.3
Keywords: Cc:
Blocked by: Blocking:
Description

We need to run the unit tests with an XHTML doctype to ensure that everything passes.

Attachments (0)
Change History (18)

Changed September 03, 2011 02:52PM UTC by dmethvin comment:1

component: unfiledbuild
milestone: None1.7
owner: → dmethvin
priority: undecidedblocker
status: newassigned

Changed October 10, 2011 04:19PM UTC by dmethvin comment:2

milestone: 1.71.8

Changed October 12, 2011 02:58AM UTC by dmethvin comment:3

milestone: 1.81.next
priority: blockerhigh

Still searching for a good solution, but this isn't a blocker.

Changed August 21, 2012 01:13PM UTC by dmethvin comment:4

Ref #12359

Changed August 21, 2012 05:59PM UTC by tomgrohl comment:5

Is it a case of copying all the tests and changing the doctype to xhtml, or is it limited to certain test.

I might be able to help on this one.

Changed August 21, 2012 06:23PM UTC by dmethvin comment:6

That's part of the investigation to be done.

For example, we support Firefox and you can serve XHTML with the right docttype and HTTP Content-Type to ensure it's interpreted as XHTML, but it just spits out console warnings if you get it wrong according to #12359. Our automated tests wouldn't catch that type of problem.

On the other hand, in #12357 it seems a Firefox XUL application demands correct XHTML to run at all. We don't have XUL on our automated tests so there's no formal support for it, but we've been able to keep it running except when we break XHTML by accident as we've done a couple of times now. There have been similar reports related to Chrome plugins.

Perhaps we can just provide some sort of XUL test in Testswarm, since that seems to be the most sensitive environment.

Changed August 21, 2012 06:39PM UTC by tomgrohl comment:7

Thanks for the info.

I'll have a look into it, see what else I can find.

Changed August 24, 2012 08:19AM UTC by tomgrohl comment:8

@dmethvin

As a starting point, I've wrote some code to check for content type and doctype.

It detects if closing tags / quoted attributes are required based on the following:

1 - content type is application/xhtml+xml

2 - content type is text/html and doctype is XHTML

3 - document is xul (Needs more testing though)

Generally is a doctype and/or content type is omitted it detaults to text/html.

This logic will be good to use and probably fix #12359 as well.

I'll now work on creating some tests for xhtml (based on the existing ones) and see where I get.

Changed September 09, 2012 01:10AM UTC by dmethvin comment:9

type: enhancementfeature

Bulk change from enhancement to feature.

Changed October 22, 2012 05:26PM UTC by dmethvin comment:10

owner: dmethvin
status: assignedopen

Changed January 04, 2013 06:59PM UTC by dmethvin comment:11

Add IE10 to the list of browsers that will generate console warnings when there are doctype-related errors. Those happen too early for a shim to console.warn to see them.

Changed April 09, 2013 02:32PM UTC by dmethvin comment:12

Although I wonder whether the shim would see them in a delay-loaded iframe.

Anway, https://github.com/jquery/jquery/commit/c6a694e1c262acb941b7fd86663f186656496bbc#commitcomment-2975014

Changed September 16, 2013 08:54PM UTC by m_gol comment:13

milestone: 1.next1.next/2.next

Changed September 21, 2013 01:39PM UTC by anthonyryan1@gmail.com comment:14

Firstly a note: The majority of the regressions in XHTML compatibility over the past few years have been in feature / bug detection code included in jQuery.

There are two approaches we can take to solving this problem, neither of which is particularly ideal:

We can run the entire test suite in XHTML mode:

Pros:

  • No duplicate tests required in the test suite.
  • All code paths are properly tested

Cons:

  • Looking through the QUnit code history, they are extremely regression prone with XHTML compatibility. We could expect regular breakage when updating QUnit unless they are similarly encouraged to test XHTML support.
  • The test running interface uses document.write() and would need to be re-implemented in a better way.
  • Some unit tests may not be possible in XHTML mode, they would require some form of indicator that they should not be run in XHTML mode.
  • As a result of the previous, some tests may be marked incompatible with XHTML when they could work just fine out of developer laziness or misunderstanding.
  • Increases the test-running time by requiring the entire suite be run mulitple times
  • iframes tests will be immune to XHTML mode setup in this way, since the iframe has it's own context. This would result is tests passing when they should fail.

Alternatively, we can duplicate specific tests to be run in XHTML iframes:

Pros:

  • None

Cons:

  • Code coverage will be poor
  • Tests will be duplicated from their HTML counterparts
  • Maintaining a list of what should be duplicated will be a maintenance burden on jQuery.

Changed September 24, 2013 08:20PM UTC by dmethvin comment:15

@anthonyryan, thanks for taking another look at this. I agree that none of the solutions are ideal, and it does get harder now that we are doing the feature detects on an as-needed basis. I'm thinking we may still want to do some sort of basic-functionality test with XHTML, at least it would give us some hope of avoiding these kind of recurring regressions.

Changed September 25, 2013 03:28AM UTC by gibson042 comment:16

True, just loading jQuery in an iframe and invoking the parent callback on successful load would go a long way. Per-module tests can come later, and need not be much more complicated either.

Changed April 30, 2014 09:47PM UTC by m_gol comment:17

Replying to [comment:15 dmethvin]:

@anthonyryan, thanks for taking another look at this. I agree that none of the solutions are ideal, and it does get harder now that we are doing the feature detects on an as-needed basis.

In test/support.js we force-compute all support tests to check if they match our expected matrix so that's not a problem.

Changed October 20, 2014 11:34PM UTC by m_gol comment:18

resolution: → migrated
status: openclosed