Browser Tools and Testing WG, WebDriver spec -- 12 Nov 2013

<wilhelm> (We're waiting for the last laggards, starting a little later than planned.)

<scribe> scribe: simonstewart

<wilhelm> Scribe: simonstewart

Introductions

MikeSmith asks if there's anyone new

garykac Gary Kacmarcik

garykac from Google

<garykac> s/Kacmarik/Kacmarcik/ ^_^

Alois Reitbauer - interest in console api

MikeSmith: no-one's working on the console api right now, but if we had an editor

More introductions (same as yesterday)

wilhelm, MikeSmith, MarcFisher

Observer introductions

wilhelm looks up meeting agenda

First topic: interactions

<wilhelm> http://www.w3.org/wiki/WebDriver/2013-TPAC-F2F

garykac: the components that the DOM spec needs.

Mouse is pretty simple: just need mouse move, over, etc. Seems straight forward

Keyboard events: want to be able to test US ASCII, but also international keybaord. Want to test "given a layout, what events are generated"

Being able to automatically change layout is desirable.

Also generate dead keys

Also creating IME composition events

Those are the big things. Undoubtedly need more

<wilhelm> Scribe: wilhelm

simonstewart: Mouse is pretty easy.
... There's a limited range of APIs that we're expecting to generate.
... click, dbclick, contextclick, mousedown, mousedown.
... OS-level.
... These events are on the other side of the glass.
... How does the browser process all these things?
... We discussed yesterday scroll wheel.

garykac: Would that include ticks? There's pixels and ticks.

simonstewart: Undecided.
... Keyboard: presskey, releasekey, send a string of characters
... Just a charsequence.
... With webelement.sendkeys, we allow people to send internationalized text

garykac: For Japanese, I don't want to send the full string.

simonstewart: The commands on webelement are do-as-I-mean.
... The advanced actions are do-as-I-say.
... Initial implementation just blasted the value in.
... To do the second case, there is the ability to have a IME engine in the open source web driver.

MarcFisher: There are functions to call, but they are not neccessarily working.

simonstewart: IME-handler
... Will list the available engines.
... Your test will be very brittle, as it relies on a specific IME engine.

garykac: Scan code?

simonstewart: Initial implementation does some calculation to figure out the scan code. Specify A, queries the OS.

garykac: This needs to be controlled in the tests.
... I want to test A on a French keyboard...

simonstewart: We're not an OS level automation API, but browser. We'll take advantage of the machine.
... For testing multiple keyboards, you may need multiple VMs.

garykac: That will not work.

simonstewart: I'm not aware of any cross-platform IME...

garykac: I thought we'd have OS specific components.

simonstewart: And we attempt to mask that.
... ChromeDriver, Marionette inject events right into the event queue.
... Looks like it comes from the OS.
... FFdriver and IE on Win uses Win32 APIs.
... Error-prone.
... The OS makes some assumptions about focus of windows.
... For accurate emulation, you need to go through the Win32 APIs.
... These tests take a long time to run.
... Must be able to run without focus, for parallell processing.
... spec has three audiences: People writing tests for their web apps.
... Browser vendors.
... Spec editors.
... Low-level, cross-platform method is incredibly challenging.
... TBH, we don't ahve the expertise around this table.
... Maybe you.

garykac: Injecting keyboard events into @@ is something that we do.

simonstewart: Unfocused windows?

garykac: Win yes, Mac no.

simonstewart: Mac has a mouse window and keyboard window.

garykac: I have less concern about the machine doing something else.
... Interop between browser vendors. Difficult to run tests will not be run.
... You inject cooked browser events?

simonstewart: Depends on the broser implementation.
... IE: three methods. Synthetitc JS events.
... A library I wrote.
... Attempts to put raw events into the Windows message queue.
... Scan codes, et.

c
...3: Use something like sendkeys.

garykac: Concern: Translation from OS events...
... Given this sequence on Windows, all browsers should get the same.

simonstewart: Out of scope?

dburns: In the way we insert trusted events into the browser, we depend on library in browser.
... Mobile, desktop.

simonstewart: Mobile is maybe the best case.
... Uses accessibility API.
... Good emulation by accident.
... Suggestions on how this can be done?
... We don't want to give the browser window OS focus.

garykac: There's parts of it that can be used.
... Mouse will be useful.
... If we're not generating the keys on the OS level, that might not fit.

simonstewart: Huge problem.

garykac: Huge because it's lots of small things.

simonstewart: And you've got at least two axes. OS, browser.
... IME, third axis.

garykac: Different keyboard layouts.

simonstewart: French dvorak...

garykac: SOme keys are not exposed...
... Writing OS specific tests must happen for this

simonstewart: Does Win32 sendkeys do what you need?

garykac: We sometimes want to know what the physical key is. Need more information.

simonstewart: The IME implementation we had worked on Windows and Linux.
... You could take these from the project.

<AutomatedTester> https://code.google.com/p/selenium/source/browse/#git%2Fcpp%2Fimehandler

<AutomatedTester> https://code.google.com/p/selenium/source/browse/#git%2Fcpp%2Fwebdriver-interactions

<AutomatedTester> https://code.google.com/p/selenium/source/browse/cpp/webdriver-interactions/interactions.cpp

simonstewart: *explains code just posted above*
... *explains relationship between Selenium / WEbDriver*
... You can use WebDriver to get the browser to a specific palce.

garykac: Can it check the OS state?

simonstewart: No
... *proposes a mixture of WebDriver + native OS code*
... If this was easy, we'd have done it.

garykac: I want to reuse as much as I can.
... Where are the live, valid sets of tests?

wilhelm: web-platform-tests

simonstewart: If you have suggestions for teh API, given our constraints.
... *lists currrent API*

garykac: Everything else comes from that.

simonstewart: Using PUA from Unicode to specifiy other characters.
... Return key, etc.
... Based on meaning.

garykac: DOM3 har those based on meaning.
... UI events has keynames based on the physical key.
... This key, Q, on English keyboard, is the same no matter which keyboard layout you have.

<simonstewart> http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/Keys.html

garykac: If you have to give the name to a physical key, use UI events.

simonstewart: *refers to the key list from the implementation*

<garykac> UI Events: http://www.w3.org/TR/uievents/

<AutomatedTester> https://code.google.com/p/selenium/wiki/JsonWireProtocol#/session/:sessionId/element/:id/value

garykac: Is this all?

simonstewart: Non-printable.

garykac: No location field to indicate it's from the keypad?

MarcFisher: Just a string.

garykac: *ask about specific keys in the list*

MarcFisher: suggestions for improving the API are welcome.

garykac: We've worked on speccing the list of keys in DOM3.

<garykac> DOM3 Events: http://www.w3.org/TR/DOM-Level-3-Events/

<simonstewart> http://www.w3.org/TR/DOM-Level-3-Events/#key-value-tables

<garykac> Section 6.3

garykac: Section 6.3
... I'm going to be merging the UI events stuff into this.
... SO that there is one canonical document.
... UI events provides more info on how awful keyboards are...
... This maps to Windows virtual keys.
... Assumes we have a location field.
... This is only the non-printable.
... Separator?
... This also includes old keys.
... Media keys.
... You may want to refer to this and say "this is where we get our values from".
... You may need location fields.
... This completely ignores Android + FirefoxOS, which we also need.

simonstewart: So far we haven't needed most of these keys...

garykac: Thank you for the information!

simonstewart: I've learned a lot about the horror that is keyboards.
... Reviews of our sections on this would be very helpful.

<scribe> ACTION: Add scrollwheel support [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action01]

PFWG PFWG

Michael Cooper, staff contact

@@, observer

@@, with IBM

MichaelC: A number of us were here at TTWF. Some of this may be familiar.
... We want to sync the accessibility testing with other testing.
... THis is an iteration of these efforts.
... IN the past few days we've got a better understanding.
... Suggested agenda items:
... Developing accessbility tests from the point of view of a developer who wants to ensure accessibility in the UA.
... We test tools, content.
... We talked about how WebDriver can be used to test web pages in UA to see if accessibility features work as intended.
... May depend on things from WebDriver.
... How can we use WD to test accessibility tests?
... We develop ARIA, which could be tested that way.
... Considering accessibility tests that can be done like the testharness.js, reftests...
... If we wish to add tests?

wilhelm: tobie's department.

MichaelC: Mapping accessibility APIs to testing...
... Accessibility vs DOM.

Janina: The best defined are the UA interfaces to accessibility API.
... On their way to Rec.
... We're looking at that approach for basis for furhter work.

MichaelC: What level of shared knowledge do we have?

simonstewart: *describes the purpose and functionality of WebDriver*

@@: JS in the browser?

simonstewart: No.

@@: Are you using Windows automation?

simonstewart: It depends.
... We need to be able to test browsers without window having focus.
... We should be able to background the window.
... (Describes the three types of events and their implementations.)

Cynthia: Assisstive technologies use OS accessibility layers to interact with f.x. UA.
... Old MS API, IBM API, newer MS Windows automation...
... Windows UI automation was designed with a couple of ideas that are different.
... To be used as a test driver in addition to accessibility.
... Combine patterns. Invoke, selection.
... "This is an invokable thing, not just a button"
... You can combine patterns.

MichaelC: The accessibility APIs do similar things, but vary between OSes.

Janina: Linux accessibility layer used for testing Linux desktop.

<simonstewart> What was the name of the linux project that uses accessibility testing?

Cynthia: You're doing platform-specific work.

simonstewart: Yes, but hidden behind the APIs.

Cynthia: We look at the markup in ARIA or HTML and our document, "this document should have these properties".

simonstewart: Forms of accessibiltiy testig already done with WD include: test tabindex.
... We also had element-by-ARIA.
... Could be used via XPath.

Janina: Would have been useful.

simonstewart: We disucussed the equivalent of a DOM in accessibility.
... Maps to DOM.

Cynthia: This exists, but outside the browser.

Jason: Some UAs already have OS-level accessibility integration. Unifying would be good.
... Interested in interaction between this approach of testing with WebDriver and Indie UI.

MichaelC: They are do what I mean-events.

simonstewart: *describes the three audiences of WebDriver*
... It sounds like you're interested in the first audience, third audience.

MichaelC: Third audience.

<simonstewart> (spec authors)

Cynthia: Adding accessibility tests to web application tests...
... WCAG has techiniques for testing. Automation? Done manually now.

Janina: Can you tab to the submit button?

simonstewart: You may be able to do a lot of it already.
... Tabbing stuff should be easy.
... WebDriver has findElementByTagName.
... Tab, find the active element.

Cynthia: img.onclick, etc. are tricky. Buttons are not.

simonstewart: Finding elements with a click handler is more difficult.

MarcFisher: But possible with JS.

MichaelC: Challenge with accessibility spec testing: we have to test how the spec shows up in different accessibility APIs.

Cynthia: You are using some of those APIs for driving?

simonstewart: Chrome and Firefox inject blessed events into their event queues.
... Nowhere near OS.
... We're trying to avoid the OS-level stuff, because the requirement of not having window focus is important.
... QAs often don't ahve more than one machine. Must be able to test while doing other work.

<scribe> ACTION: Cynthia to find the right people at MS to talk about UI automation [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action02]

MichaelC: I want to get to a next-steps-hase.

Janina: We're closing on ARIA 1.0.
... 1.1 is interesting. Sovling new problems.

simonstewart: How would you like ARIA 1.0 to be exposed?

Cynthia: You're always going to be looking at the role.
... Actual attributes.

MichaelC: We're looking at the accessibility API...

Cynthia: COmpare expected results with outout from OS-level API.
... Testing that the markup was mapped correctly to the API.
... Manually, using inspector.
... SOme of these tools are automatable.

simonstewart: Focus of WD is automating the browser. Already a massive challenge.
... If there was some common accessibility DOM in the OS, that can be integrated with WebDriver.

<simonstewart> Not OS: browser

<simonstewart> /accessibility DOM in the OS/accessibility DOM in the browser,/

MichaelC: It sounds to me that WebDriver would help us do some testing of the accessibility specs.
... BUt not a lot.
... We've mostly been avoiding those, as they are all manual.
... We can improve our test suite with automation.

simonstewart: WD is a library you can use to poke the browser. You could use another library to poke the OS accessibility layer.

MichaelC: More potential for accessibility testing re: WCAG.

simonstewart: If there's something we can do to facilitate testing of accessibility in web applications.

Cynthia: Something that comes up as a button in the accessibility API can be any element with role=button.

simonstewart: It would be interesting to track progress on Accessibility DOM.

<scribe> ACTION: Our group to take a look at WCAG hard fails and understand them [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action03]

<MichaelC> WCAG 2.0 Techniques

http://www.w3.org/TR/WCAG20-TECHS/

<simonstewart> That's a huge amount of work

MichaelC: *explains how WCAG techniques are described*

Cynthia: These are the most common failures.

MichaelC: We should keep in touch.

dburns: Probably F2F in Q1 in California.

MichaelC: By then, we could have a proper agenda. This is more of an exploratory meeting.

Break

We resume at 11:30.

<gitbot> [13web-platform-tests] 15zcorpan closed pull request #431: Update the VTTCue test names (06master...06vttcue-title) 02https://github.com/w3c/web-platform-tests/pull/431

<simonstewart> MichaelC: thank you!

Charter and plan forward

MikeSmith: Our charter expires at the end of the year.
... dburns has already posted on the list about this.

dburns: What we're proposed is LC around March next year.

Q1 vs Q2?

simonstewart: MY suggestion was aim for Q2, with a checkpoint at the end of Q1.
... If we give us a too tight deadline and fail to meet that, rechartering will be a pain.

<simonstewart> wilhelm: we keep on setting dates in the calendar, but first of all we need to figure out what needs to be done to get the spec and test suite to where it needs to be

<simonstewart> scribe simonstewart

<simonstewart> wilhelm: we keep on setting dates in the calendar, but first of all we need to figure out what needs to be done to get the spec and test suite to where it needs to be

<simonstewart> ... does that make sense

<simonstewart> ?

<dom> scribenick: simonstewart

MikeSmith: I don't think it makes that much difference on what we decide. We do need to demonstrate progress and milestones to aim for
... as long as we have that, we're ok

plh: can go to management and say that things are moving forward, though not at LC yet
... just a mattter of convincing colleagues. Not currently getting pressure to actually getting it finished.

AutomatedTester: Another nice thing is that we're further along in the implementations than we are in the spec.

plh: only thing I'm worried about is people who aren't sponsored by a company being able to make meetings

wilhelm: one other thing that we've discussed is scope creep. Solution proposed earlier is to move unstable pieces to a separate document

plh: that's a common solution

AutomatedTester and simonstewart: both happy to edit two documents

MikeSmith: other thing I want to ask about is extension duration. Is there an outside limit?

plh: two years is a limit, but as a checkpoint

MikeSmith: not planning on making any changes to the charter itself.

plh: try to be realistic

simonstewart: so, milestones. Work items first

MikeSmith: testing and spec work are the two pieces.

simonstewart: going through the spec and identifying things to pull out into 1.1 and fill out placeholders

wilhelm: also need to look at the OSS test suite for things that need to be specified
... suggests going through the OSS test and adding official tests and placeholders for the spec
... added a wiki page (webdriver/testsuite) started listing tests we don't have but should

simonstewart: do we want to go through that suite now?

wilhelm: split up and do in parallel
... maybe that's a day's work per chapter?

MikeSmith: set some milestones

wilhelm: should probably base those on labour

simonstewart suggests writing up possible milestones. MikeSmith starts writing

<scribe> ACTION: Milestone 1: go through OSS test suite and identify tests to copy to official test suite. [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action04]

<scribe> ACTION: Milestone 2: add placeholders for areas not already specified [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action05]

<scribe> ACTION: identify sections in existing spec to move to 1.1 [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action06]

simonstewart: shall we try and identify the areas to remove now?

wilhelm: ok

<AutomatedTester> scribe: AutomatedTester

<simonstewart> http://www.w3.org/TR/webdriver/

<simonstewart> https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html

<MarcFisher> https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html

simonstewart: 7,4 to be removed

MikeSmith: are we dropping or moving?

simonstewart: moving to 1.1
... 11.4 reporting errors on JS errors to be moved to 1.1

MarcFisher: and its completely empty so thats fine

<scribe> ACTION: David Burns, completing 17.2 [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action07]

simonstewart: move 17.3 to 1.1
... this is all based on the working published versions

<scribe> ACTION: David Burns upstream element screenshotting [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action08]

simonstewart: missing the HTTP normalisation which is important for 1.0 and we need to put that in

<scribe> ACTION: simonstewart to add HTTP normalisation for the JSON Wire Protocol [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action09]

MarcFisher: logging is missing

simonstewart: I have that half written already

wilhelm: IME? lets move that to 1.1
... its currently unstable in all implementations

simonstewart: DOM events, UI events... do we want to work with that in 1.0 or 1.1?

wilhelm: is that important for now?

simonstewart: our keyboard mappings are how we encode them for sending them over the wire
... our commands are simple

Mfisher: we may need to tweak

simonstewart: at a later version we may need to add to handle more DOM Events

mfisher: keyup and keydown is missing?

simonstewart: its implemented in the OSS project for all browsers

mfisher: the Dart implementation may not have this information

simonstewart: are there other ommissions that we need to put in
... we will move authentication to 1.1
... (explaining how authentication may work in the future)
... Basic auth is important bug on the OSS project

<simonstewart> https://code.google.com/p/selenium/issues/detail?id=34

(all discussing connecting to a running browser)

simonstewart: HTML5 offline technology, do we care ?

MikeSmith: lets no worry about the offline tech
... Geo location?

wilhelm: should we move it to 1.1 or hold up 1.0 for it?

automatedtester: lets move geolocation to 1.1

(all agree)

<simonstewart> https://code.google.com/p/selenium/source/browse/#git%2Fjava%2Fclient%2Ftest%2Forg%2Fopenqa%2Fselenium

wilhelm: how many unique tests in that repo?

simonstewart: 600-700
... checking its actually over 1000 tests

<simonstewart> (in the root of the OSS project)

<wilhelm> http://www.w3.org/wiki/WebDriver/Test_suite

wilhelm: based on this data we can start to make realistic estimates
... I used to do 30minutes to 1h so that is a lot of time on that alone

simonstewart: do we have proxy configuration in the spec?
... we dont appear to have that

MarcFisher: that is a lot of tests and 30 is very conservative. We could automate this

AutomatedTester: we need to do manual checks agains the spec when converting so we can't automate it

MarcFisher: it could still be ~300 hours

wilhelm: lower than 10 minutes per test is day dreaming

simonstewart: do we have implicit and explicit timeouts

MarcFisher: we already have timeouts

<simonstewart> 878 tests. Ish. To port.

simonstewart: we have 878 tests according to my command line tool

MikeSmith: who is going to review those?

simonstewart: David and Simon
... tests are easy to move

AutomatedTester: Andreas Tolfsen has been reviewing too

MikeSmith: we own that section and dont need others for review?

simonstewart: no we can do that

wilhelm: how much effort to do the prose in the spec?

simonstewart: we need to visit 10.1 again and clean that up

MarcFisher: 14 needs to be fleshed out
... section 6 needs more prose

simonstewart: we can move 6.6 to 1.1
... we need to get someone to look at the webidl

<simonstewart> http://www.w3.org/TR/WebIDL/#dfn-dictionary

AutomatedTester: Dictionary wasnt useful and there is an outstanding bug. I have looked at the alternatives but the don't know what is useful

<scribe> ACTION: David Burns to speak to heycam or bz about WebIDLs needed [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action10]

(discussion about thread safety)

simonstewart: for fleshing out the text would be 2-3 weeks
... does logging and http
... David Burns can do user inputs
... and others can help too
... and then a few editing passes are required

we need to fix the WebIDL output

MikeSmith: we are going to be doing snapshots regularly but we are getting away from that in other groups
... we are going to be removing TR from robots.txt
... to make sure implementors always find the editors draft

wilhelm: we could do this regularly

MikeSmith: to get to TR we need to pubrules within W3C
... lets worry about editors drafts for now

wilhelm: can we tell people to use the editors draft

<scribe> ACTION: MikeSmith to put a note on the TR to tell people to use the editors draft [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action11]

MikeSmith: based on this and we need to think about when we will hit LC

wilhelm: we are looking at 600hrs worth of work

simonstewart: I am freeing up 1/2 a day a week

automatedtester: I am getting more free time

MarcFisher: I should be able to do 1/2 day a week too

AutomatedTester this is roughly 75 work days (600/8)

ShuotaoGao: I can do that too

MarcFisher: we can do 3/4 days a week by the sounds which is ~36 weeks

simonstewart: maybe we do a writing week on this

(discussing F2F next year to get people to work on spec)

Lunch!

<wilhelm> We reconvene at 14:00.

<jgraham> So, if anyone at TPAC cares, I am about to talk about test code review and demo review tools including critic in WebApps

<jgraham> There are plenty of spaces

<darobin> ah shit, I'm in another meeting

<ArtB> (Shenzhen meeting room)

<ArtB> if you hurry, we can try to find an empty seat for you ;)

MikeSmith: hey, do you need help from a Bugzilla dev?

<simonstewart> scribe: simonstewart

The Way Forward

AutomatedTester: Before lunch we were talking about 36 weeks to get everything done.

wilhelm: that takes us to the 22nd July

MarcFisher: we could drop that down if we did more work per week

AutomatedTester: That plus one week contingency. Suggests 1st August 2014 as the LC date

wilhelm: suggests a full year extension to the charter

AutomatedTester: Not sure how long between LC and CR, and then REC

MikeSmith: LC comments period is a minimum of three weeks
... commonly extends to six weeks
... most people wait until the end of the LC comment period before submitting comments
... takes a week or so until after comments close before you normally publish another draft
... need to write up a Disposition of Comments documnet
... minimum of a month from LC to CR.
... One thing to mention: we could skip CR so long as we were confident that we would meet our CR exit criteria (normally 2 interoperable implementations)

<scribe> ... (done by each statement in the spec that gives a conformance requirement)

UNKNOWN_SPEAKER: Can do this if you say upfront in the LC draft to transition directly to PR

simonstewart: would we need to recharter to handle 1.1?

MikeSmith: the charter doesn't limit us to only one document

wilhelm: should we charter for two more years so that we can move to 1.1 after 1.0?

MikeSmith: we don't need to come up with a new charter if there's a new deliverable after 1.0
... suggests chartering for two years
... within two years we may want to recharter. Or we could declare victory and finish
... Though I think we should keep the group open, since people will start reporting issues once they start using the spec.
... * the story of XSLT 1.0 in browsers *

wilhelm: suggests describing 1.0 as a feature set, rather than "being complete", to allow for changes

MikeSmith: this gets to the difference between a living standard, or having separate levels.
... within the W3C model, levels seems like the way to go.
... So for now aim for LC in August? Build into the schedule a CR period, but can consider in August if we need to

simonstewart: Everyone agree?

* everyone agrees *

<scribe> ACTION: MikeSmith: write up schedule ASAP for getting us the extension from plh. [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action12]

wilhelm: shall we set some tentative dates for the next f2f?

simonstewart: February?

MarkFisher: some time in Q1

AutomatedTester: suggests last two weeks of February.

simonstewart: Last week of Feb

wilhelm: week of Mon 25th Feb

AutomatedTester: mozilla to host

<scribe> ACTION: AutomatedTester get agreement for Mozilla to host [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action13]

AutomatedTester: Need to confirm dates with MS

MikeSmith: since it's a week, see if there are other people who want to meet up (webapps? components?)

AutomatedTester: accessibility meeting up in that time?

wilhelm: do we need a meet up in London?

AutomatedTester: not a formal one, but we will meet up

simonstewart: Looks like we're done for now.

RRSAgent draft minutes

RRSAgent: draft minutes

- DRAFT -

Browser Tools and Testing WG, WebDriver spec

12 Nov 2013

Attendees

Contents