154359 - Add 'almost standards' mode to Page Info

Status: NEW

(SeaMonkey :: Page Info, defect)

Description

[Malcolm Rowe]

With bug 153032, we now have an 'almost standards' rendering mode in addition 
to quirks and 'full standards' (the old standards mode).  This mode is 
triggered by transitional DOCTYPEs, for example.

Page info currently reports 'almost standards' mode as 'strict standards 
mode'.  See:
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/pageInfo.
js#194

This new mode should be added to Page Info to allow page authors to determine 
which mode their page is being displayed under.

Expected results:
Page info for http://www.ibm.com/ should show as 'almosts standards' mode.
Actual results:
Page info for http://www.ibm.com/ shows as 'Standards compliance mode'.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Confirmed, but this is a mode completely internal to gecko that it does not
export to any external interfaces, so there is no way for page info to find out
whether we're in standards compliance mode or almost-standards mode.

Comment 2

[Malcolm Rowe]

Agreed.  Would it be acceptable to add a new attribute to nsIDOMNSHTMLDocument  
that can provide the information that page info needs, in the same way that 
compatMode does?

Comment 3

[Daniel Brooks [:db48x]]

it should just use a different value for document.compatMode

once that's done it's extreamly simple on the page info side of things.

Comment 4

[Boris Zbarsky [:bzbarsky]]

*** Bug 154461 has been marked as a duplicate of this bug. ***

Comment 5

[Daniel Brooks [:db48x]]

fwiw, I wouldn't call it 'almost standards mode'. 'transition standards mode'
might work though.

Comment 6

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

I suggest avoiding the words "Transitional" or "Strict" when decsribing the
modes. Calling the standards mode "strict mode" has caused enough confusion already.

Comment 7

[Malcolm Rowe]

I got the impression that document.compatMode was intended to be compatible 
with the Microsoft implementation - see bug 105640 and
http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLDocument
.cpp#3328

If so, I'm not sure it would be a good idea to break that compatibility by 
returning a different value in this case.  That's why I suggested adding a new 
method.

Regarding naming - we now have three modes, which are described as follows:
eCompatibility_NavQuirks        Quirks mode
eCompatibility_AlmostStandards  ?
eCompatibility_FullStandards    Standards compliance mode

Perhaps 'Partial standards compliance mode'? Why not 'Almost standards 
compliance mode'?

Comment 8

[Malcolm Rowe]

Attachment: Proposed patch

This demonstrates what I was suggesting - add a new property to
nsIDOMNSHTMLDocument and base the Page Info text off that.

Note that I've not attempted to build this at all.

Comment 9

[Daniel Brooks [:db48x]]

That would work (probably even compile as well), but I don't see why we can't 
just add another value to the property we have.

Comment 10

[Malcolm Rowe]

People do seem to be interested in maintaining compatibility with MSIE's 
compatMode property.  See in particular jst's comment in bug 105640 comment 10.

For reference, the following MSDN article describes the property:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.
asp

I think that we should either remain completely compatible with MSIE, and 
therefore add a new property for our purposes, or be completely incompatible 
and return completely different values for document.compatMode (ie, 
not 'CompatMode', 'CSS1Compat').  I don't think it's helpful to have a property 
that looks and works like MSIE's property, and that *occasionally* returns a 
completely unexpected value.

Comment 11

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Mozilla's Standards mode is more about CSS2compat than about
CSS1compat--particularly if you consider the difference with Almost Standards. :-)

Comment 12

[Malcolm Rowe]

cc'ing jst to see if he has any comments to make about adding/changing 
properties on the DOM document object.

Comment 13

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Is there any chance of this making it into 1.0.1?

Comment 14

[Johnny Stenback (:jst)]

No.

Comment 15

[Johnny Stenback (:jst)]

I really don't think the "need" to show this info in the page info dialog is
nearly reason enough to add a new property to the DOM (or break compliance with IE).

I'd much rather see the logic that the parser uses duplicated in the page info
dialog if this is that important, polluting the DOM with this seems like a bad
idea to me.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Duplicating the parser's logic is not a good idea.  If we want this it would
make more sense to add something to nsIContentViewer, which is exposed within
the app but not to web pages using the DOM.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

actually, probably nsIMarkupDocumentViewer would be more appropriate.

Comment 18

[Johnny Stenback (:jst)]

Sure, that's fine with me.

Comment 19

[Malcolm Rowe]

Nominating for Mozilla 1.1.  Now that 'almost standards' mode is getting some 
awareness, it's going to be more important for authors to verify what mode they 
are operating in.

(For example, 
http://www.evolt.org/article/New_DOCTYPE_sniffing_in_upcoming_Mozilla_releases/1
/32271/index.html)

I've taken a look at the code, but I've not got enough experience to understand 
exactly what would need doing.  If someone can sketch an implementation, I'll 
attempt a patch.

Comment 20

[Mats Palmgren (inactive)]

I agree with Malcolm, correct info on which mode is used is much needed.
Saying "Standards compliance mode" when it's not is bad.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, don't be so sure that this is a permanent fix (and that almost-standards
will last forever).  CSS3 will almost definitely provide a solution that we can
use to solve this with rules in the UA stylesheet (that would even apply in full
standards mode), and we're likely to implement that at some point (and probably
as one of the higher-priority parts of CSS3).

Comment 22

[Jeremy M. Dolan]

How about calling them something like:

Standards compliance mode with CSS1 compatibility
Full standards compliance mode

or

Standards compliance mode (with transitional CSS1)
Standards compliance mode

Also, there should be a help page or something for that page info dialog, that
could point users (or rather, developers) to
http://mozilla.org/docs/web-developer/quirks/doctypes.html as the explaination
of that field.

There's no way currently to find out what mode I'm in, other than adding
something to your page to see how line-height behaves, is there?

Comment 23

[Sam Katz]

re: <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=154359#c19">comment
19</a> or <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=154359#c22>comment 22</a>:

I agree. We either need to:
a) accept this current patch as the solution until CSS3.
b) discuss what would be needed to implement additional text or a link
explaining this dialog further.

I knew enough about Mozilla to know that it wasn't rendering in
"standards-compliance" mode--it was running in "almost-standards compliance
mode", because I copied the doctype from the devedge article.

Other developers may get scared and remove the doctype, fearing that it will
break subpages.

--Sam

Comment 24

[Malcolm Rowe]

The current patch is no good (see comment 15). At one time, I did start on an 
implementation based on comment 17, but (IIRC) I couldn't figure out how Page 
Info could obtain a reference to the correct nsIMarkupDocumentViewer.

Comment 25

[Mats Palmgren (inactive)]

Daniel, I hope you don't mind if I steal this bug...
I have patch according to comment 17.

Comment 26

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 27

[Mats Palmgren (inactive)]

Attachment: Screenshot (patch rev. 1)

Comment 28

[[e-mail]]

Comment on attachment 170681 [details] [diff] [review]
Patch rev. 1

>   /**
>+   * Layout mode: see layout/base/nsCompatibility.h for values.
>+   */
>+  readonly attribute PRInt32 compatibilityMode;
Perhaps you should move the values here?
You also forgot to rev the iid.

>+/* The #modetextlink style is based on the "Get New Themes" link in the pref panel */
>+#modetextlink {
>+  text-decoration: underline;
>+  color: blue;
>+  cursor: pointer;
>+}
>+
>+#modetextlink:active {
>+  color: red;
>+}
The fact that these work depends on a bug in pageInfo.css not declaring a
default namespace. We really ought to share this style with the similar one in
prefpanels.css somehow.

>Index: browser/locales/en-US/chrome/browser/pageInfo.properties
I don't think this change belongs here ;-)

>+              <hbox><html:a id="modetextlink" style="display:block" href="&generalModeURL;" target="_blank"/></hbox>
html should be wrapped in a label or description element, not forced to fit
with display:block and hbox hacks.

>+    compatibilityMode =
>+      window.opener.gBrowser.docShell.contentViewer.QueryInterface(Components.interfaces.nsIMarkupDocumentViewer).compatibilityMode;
This won't work for View Frame Info.

>+      document.getElementById("modetextlink").innerHTML = theBundle.getString("generalStrictMode");
Use .textContent for text, not .innerHTML

Comment 29

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 30

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

(In reply to comment #28)
> >Index: browser/locales/en-US/chrome/browser/pageInfo.properties
> I don't think this change belongs here ;-)

I don't get it. Why should this file not be updated?

> This won't work for View Frame Info.

I could not find a simple way to get from "document" to "nsIDocShell", so
I had to traverse the docShell tree looking for the one with the document.

Comment 31

[[e-mail]]

Comment on attachment 170754 [details] [diff] [review]
Patch rev. 2

>Index: browser/locales/en-US/chrome/browser/pageInfo.properties
>Index: toolkit/content/xul.css
Please don't mix suite and firefox patches.

>+              <label><html:a id="modetextlink" href="&generalModeURL;" target="_blank"/></label>
I notice that all the textboxes gave been given zero margin. Please could you
give the label a class so you can style it in pageInfo.css to match.

>+    var iter = window.opener.gBrowser.docShell.getDocShellEnumerator(Components.interfaces.nsIDocShellTreeItem.typeContent,
>+                                                                     Components.interfaces.nsIDocShell.ENUMERATE_FORWARDS);
>+    while (iter.hasMoreElements()) {
>+      const docShell = iter.getNext().QueryInterface(Components.interfaces.nsIDocShell);
>+      const webNavigation = docShell.QueryInterface(Components.interfaces.nsIWebNavigation);
>+      if (webNavigation.document == theDocument) {
>+        compatibilityMode = docShell.contentViewer.QueryInterface(Components.interfaces.nsIMarkupDocumentViewer).compatibilityMode;
>+        break;
>+      }
>+    }
Boris Zbarsky knows a better way to get a doc shell.

>+html|a:link {
>+  text-decoration: underline;
>+  color: blue;
>+  cursor: pointer;
>+}
>+
>+html|a:active {
>+  color: red;
>+}
Hmm... perhaps these should be :link and :link:active?

Comment 32

[Boris Zbarsky [:bzbarsky]]

> I could not find a simple way to get from "document" to "nsIDocShell",

document.defaultView.QueryInterface(Components.Interfaces.nsIInterfaceRequestor)
        .getInterface(Components.interfaces.nsIWebNavigation)
        .QueryInterface(Components.interfaces.nsIDocShell)

should work....

Comment 33

[Daniel Brooks [:db48x]]

I'll add in my two cents. First, don't use window.opener, use theDocument.

Second, do patch both xpfe and browser at the same time - it's the only way to
keep them in sync. However, your patch doesn't include changes for browser's
pageInfo.js, pageInfo.xul, pageInfo.dtd, or skins.

Third, I don't really care for that to be a link. It's an interesting idea, but
I think the information is best put into the help file.

Comment 34

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 35

[Frank Wein [:mcsmurf]]

I think we can actually confirm this bug now as it's still there.