Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 11 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 496376

Blocking:
issue 674593
issue 238234


Show other hotlists

Hotlists containing this issue:
Non-Standard-IDL


Sign in to add a comment
HTMLDocument is dead. Long live Document
Project Member Reported by arv@chromium.org, May 6 2013 Back to list
https://bugs.webkit.org/show_bug.cgi?id=110772

The DOM specs now use Document instead of HTMLDocument.

http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
http://dom.spec.whatwg.org/#domimplementation

"For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object."
 
Comment 1 by arv@chromium.org, May 6 2013
Blocking: chromium:238234
Comment 2 by arv@chromium.org, May 6 2013
Cc: esprehn@chromium.org abarth@chromium.org eseidel@chromium.org
I'm a bit concerned about making Document.{h,cpp} even larger.

We could probably get away with just making changes to the idl files but that seems pretty hacky.
Hmm, so this means all XML documents you load through XHR get all the crazy HTML stuff on them too eh? That seems really bizarre that those get designMode and activeElement too, but I guess so...

We should just merge the files. The full screen stuff in Document should be moved out and that'll make things smaller.
Comment 4 by arv@chromium.org, May 6 2013
You can get an HTMLDocument without a view today. designMode and activeElement needs to be able to bail out for those anyway.
Right, but what about:

document.implementation.createDocument().createElement('div')

Does that return an HTMLDivElement now? It didn't used to.
Comment 6 by arv@chromium.org, May 6 2013
createDocument needs a namespace. If we assume that it will default to a null namespace like today this will create an Element object and not an HTMLDivElement. I don't think this will change the behavior in any way.
document.namespaceURI is always null, is there any way to get the namespace of a document to know if createElement is going to return an Element or an HTMLElement? Perhaps document.namespaceURI should return something instead of null. I guess people can just create a div and see what happens.
Comment 8 by arv@chromium.org, May 6 2013
document.implementation.createDocument returns an XMLDocument. I'm not sure if XHR ever returns an XMLDocument or not. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21945 to sort this out.
XMLDocument doesn't exist, where is that interface specified?
document.implementation.createHTMLDocument is probably what you're looking for if you want to make a viewless HTML document.
Project Member Comment 12 by bugdroid1@chromium.org, Feb 26 2015
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=190897

------------------------------------------------------------------
r190897 | philipj@opera.com | 2015-02-26T09:47:06.657003Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/DOMImplementation.idl?r1=190897&r2=190896&pathrev=190897

Sync the DOMImplementation interface with the spec

https://dom.spec.whatwg.org/#interface-domimplementation

BUG= 460722 , 238368,  335871 ,  429536 

Review URL: https://codereview.chromium.org/960533003
-----------------------------------------------------------------
Comment 13 by phil...@opera.com, Jun 3 2015
Blockedon: chromium:496376
Labels: -Cr-Blink
Comment 15 by tkent@chromium.org, Apr 19 2016
Cc: -eseidel@chromium.org -abarth@chromium.org
Labels: Hotlist-Interop
Project Member Comment 16 by bugdroid1@chromium.org, Aug 2 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a

commit 3dda93ba7fa7ae42912dbdeae479b785eac0fe9a
Author: foolip <foolip@chromium.org>
Date: Tue Aug 02 14:35:36 2016

Remove unnecessary uses of HTMLDocument

Most of HTMLDocument has already been merged into Document, so these
code paths no longer anything HTMLDocument-specific.

Drive-by:
Remove some unnecessary includes and fix typo in HTMLDocument.cpp

BUG=238368

Review-Url: https://codereview.chromium.org/2197953002
Cr-Commit-Position: refs/heads/master@{#409188}

[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/css/AffectedByFocusTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/css/DragUpdateTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/dom/custom/CustomElementReactionStackTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/dom/custom/CustomElementsRegistryTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/dom/shadow/FlatTreeTraversalTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/editing/FrameSelectionTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/editing/GranularityStrategyTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/editing/commands/ReplaceSelectionCommandTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/HTMLDocument.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/HTMLFormControlElementTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/HTMLObjectElement.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/HTMLSelectElementTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/HTMLTextFormControlElementTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/canvas/CanvasFontCacheTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/html/parser/HTMLTreeBuilder.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/input/EventHandlerTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/layout/LayoutThemeTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/loader/FrameFetchContextTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/loader/HttpEquiv.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/core/origin_trials/OriginTrialContextTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/modules/canvas/HTMLCanvasElementModuleTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DAPITest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DUsageTrackingTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/modules/credentialmanager/PasswordCredentialTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/web/tests/WebFrameTest.cpp
[modify] https://crrev.com/3dda93ba7fa7ae42912dbdeae479b785eac0fe9a/third_party/WebKit/Source/web/tests/WebViewTest.cpp

Project Member Comment 18 by bugdroid1@chromium.org, Sep 9 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fac211fb17e55913cadfae4344f23b056066c7f6

commit fac211fb17e55913cadfae4344f23b056066c7f6
Author: foolip <foolip@chromium.org>
Date: Fri Sep 09 13:22:56 2016

Revert of Move HTMLDocument::isCaseSensitiveAttribute into SelectorChecker (patchset #1 id:1 of https://codereview.chromium.org/2313253002/ )

Reason for revert:
Possible cause of regression in blink_perf.parser.

BUG= 645370 

Original issue's description:
> Move HTMLDocument::isCaseSensitiveAttribute into SelectorChecker
>
> BUG=238368
> R=esprehn@chromium.org,rune@opera.com
>
> Committed: https://crrev.com/e912108e9daf83d1bec61e5b78aaacf965a3e2fc
> Cr-Commit-Position: refs/heads/master@{#416903}

TBR=esprehn@chromium.org,rune@opera.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=238368

Review-Url: https://codereview.chromium.org/2326493004
Cr-Commit-Position: refs/heads/master@{#417571}

[modify] https://crrev.com/fac211fb17e55913cadfae4344f23b056066c7f6/third_party/WebKit/Source/core/css/SelectorChecker.cpp
[modify] https://crrev.com/fac211fb17e55913cadfae4344f23b056066c7f6/third_party/WebKit/Source/core/html/HTMLDocument.cpp
[modify] https://crrev.com/fac211fb17e55913cadfae4344f23b056066c7f6/third_party/WebKit/Source/core/html/HTMLDocument.h

If anyone attempts to move isCaseSensitiveAttribute again, be sure to look at  issue 645370 . It's weird that putting it in the same compilation unit made perf worse, one would have to look at the generated code to see what's going on.
Blocking: 674593
Cc: foolip@chromium.org
Project Member Comment 22 by bugdroid1@chromium.org, Sep 19
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/808291f0d518c59d3e28c23cd9f18a004b972ee9

commit 808291f0d518c59d3e28c23cd9f18a004b972ee9
Author: Rob Buis <rob.buis@samsung.com>
Date: Tue Sep 19 16:49:31 2017

Make createHTMLDocument return a Document

As the FIXME says, instead of a HTMLDocument
we should return a plain Document:
https://dom.spec.whatwg.org/#domimplementation

Bug: 238368
Change-Id: I3dd9bf5039994ef0a98863dc0b4d4dffae23453d
Reviewed-on: https://chromium-review.googlesource.com/669459
Commit-Queue: Rob Buis <rob.buis@samsung.com>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502867}
[modify] https://crrev.com/808291f0d518c59d3e28c23cd9f18a004b972ee9/third_party/WebKit/Source/core/dom/DOMImplementation.cpp
[modify] https://crrev.com/808291f0d518c59d3e28c23cd9f18a004b972ee9/third_party/WebKit/Source/core/dom/DOMImplementation.h
[modify] https://crrev.com/808291f0d518c59d3e28c23cd9f18a004b972ee9/third_party/WebKit/Source/core/dom/DOMImplementation.idl

Comment 23 by kochi@chromium.org, Oct 16 (4 days ago)
Owner: rob.b...@samsung.com
Status: Assigned
Rob, as I see you have worked on this issue for some time,
what do you think is the criteria for this to be closed?

If something is impossible, as you commented at
https://chromium-review.googlesource.com/c/chromium/src/+/695815#message-b1820cbef62d943231db439ad296a3d3c3bc4a93

then how about documenting (in *.md or inline TODO comment) why it's
impossible, and close the issue?
Comment 24 by kochi@chromium.org, Oct 16 (4 days ago)
After reading your comment at
https://github.com/whatwg/dom/issues/221#issuecomment-336517041
I'm still confused; so moving all properties from HTMLDocument to Document,
but HTMLDocument will be an alias of Document and will be kept?
Comment 25 by rob.b...@samsung.com, Oct 16 (4 days ago)
@kochi, impossible only on binding side I think:
https://html.spec.whatwg.org/#the-window-object
"For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object."

On C++ side, HTMLDocument keeps track of named items, id and name specific to HTML. So technically this could go on Document but it seems that would bloat it a bit for non HTML usage. AFAICS this is the last item to be done for this bug, if we want to do that at all.

Finally I think you can look at whatwg discussions and see that there is less enthusiasm to completely get rid of HTMLDocument recently. I hope foolip can weigh in here :)
Sign in to add a comment