484188 - Port browser-chrome mochitests from browser/base/content to SeaMonkey

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Robert Kaiser]

In bug 484187 I'm porting the plain mochitests from browser/base/content, in here I'll be doing the browser-chrome ones that fit.

Comment 1

[Robert Kaiser]

Attachment: port over the browser mochitests

...aaaand here's the browser tests. Took me quite some work to get all that into shape, unfortunately, but now all tests should be working fine even on SeaMonkey.

I needed two small adjustments to how the page info dialog is being called so that the test for the feeds panel actually works, and there are a few TODOs that we may want to look into in followups.

Comment 2

[Robert Kaiser]

Browser Chrome Test Summary
        Pass: 90 
        Fail: 0
        Todo: 5

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_feed_tab.js | Number of feeds listed: 2, should be 3

Here we don't detect a feed that Firefox does actually detect.

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_page_style_menu.js | link 17 with rel="alternate stylesheet" and media="allscreen" should not show up in page style menu
TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_page_style_menu.js | link 18 with rel="alternate stylesheet" and media="_all" should not show up in page style menu

Those are todo() on the Firefox side as well.

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_pluginnotification.js | Should have opened the correct window
TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_pluginnotification.js | Should have displayed the plugins pane

We don't open the Add-On Manager with the plugins pane in the case that is tested here

Comment 3

[Justin Wood (:Callek)]

Comment on attachment 368350 [details] [diff] [review]
port over the browser mochitests

Looks like you forgot to hg add some of these test files (3.xml for example)

For the record we miss that feed test [compared to FF] due to not actually having a content sniffer yet for feeds (asrail is working on that iirc).

Comment 4

[Robert Kaiser]

(In reply to comment #3)
> (From update of attachment 368350 [details] [diff] [review])
> Looks like you forgot to hg add some of these test files (3.xml for example)

No, those are not needed (never actually requested), they are just dummy links. if I would have forgotten any files, hg status would have choked, and it didn't.

> For the record we miss that feed test [compared to FF] due to not actually
> having a content sniffer yet for feeds (asrail is working on that iirc).

No, what we fail is that we don't detect |rel="feed"| as a feed in page info (and probably anywhere else, but page info is test here).

Comment 5

[[e-mail]]

(In reply to comment #2)
> We don't open the Add-On Manager with the plugins pane in the case that is
> tested here
That would be bug 465771 I guess.

Comment 6

[[e-mail]]

(In reply to comment #4)
> No, what we fail is that we don't detect |rel="feed"| as a feed in page info
> (and probably anywhere else, but page info is test here).
We detect three feeds in the browser (link toolbar uses its own code but still agrees with bookmarks menu and feed icon).

Comment 7

[Robert Kaiser]

(In reply to comment #5)
> (In reply to comment #2)
> > We don't open the Add-On Manager with the plugins pane in the case that is
> > tested here
> That would be bug 465771 I guess.

Ah, thanks, added a dependency (not a real blocker as I todo()ed that part anyway, but a good reference to have when we fix the other bug).

(In reply to comment #6)
> (In reply to comment #4)
> > No, what we fail is that we don't detect |rel="feed"| as a feed in page info
> > (and probably anywhere else, but page info is test here).
> We detect three feeds in the browser (link toolbar uses its own code but still
> agrees with bookmarks menu and feed icon).

I wonder if we should port what bug 396203 introduced and keep one single list for all those places, actually.
In any case, if browser detects three and page info only two, that's another real bug we spotted with this test porting :)

Comment 8

[[e-mail]]

Comment on attachment 368350 [details] [diff] [review]
port over the browser mochitests

Oh wait, we can't have conditional tests here. The dependent bugs had better turn the tree orange if they don't update the test.

Comment 9

[Robert Kaiser]

Attachment: updated for feed panel fix

Updated for the feed panel fix.

Now I'm at the following:

Browser Chrome Test Summary
        Pass: 91
        Fail: 0
        Todo: 5

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_bug462289.js | tab key to tab activeElement

Yes, this sucks. Badly. See the comment in the code and my bad hackaround there. Somehow it tells me it ends up on a input element rather than the tab and I have no clue why. It worked earlier on my machine, then stopped working and I can't see what changed or what would be up in the window. I'd really like to see if this hits the TODO() on the official test machines as well.

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_page_style_menu.js | link 17 with rel="alternate stylesheet" and media="allscreen" should not show up in page style menu
TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_page_style_menu.js | link 18 with rel="alternate stylesheet" and media="_all" should not show up in page style menu

As said before, also todo() on Firefox.

TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_pluginnotification.js | Should have opened the correct window
TEST-KNOWN-FAIL | chrome://mochikit/content/browser/suite/browser/test/browser_pluginnotification.js | Should have displayed the plugins pane

bug 465771, as said before.

Comment 10

[Robert Kaiser]

Attachment: v 1.2: feed panel fix and somewhat sane tab focus workaround

Sorry for the fast followup but the tab focus thing in the last version was just too ugly to go in that way. I verified that I (still) seem to be at the html:input element inside the urlbar after issuing that VK_TAB so I added a workaround specifically for that so that we end up still testing what we actually want to test here, and that is that the tab can be focused with the tab key.

Comment 11

[[e-mail]]

Comment on attachment 368712 [details] [diff] [review]
v 1.2: feed panel fix and somewhat sane tab focus workaround

>+  document.getElementById("urlbar").focus();
Can you try document.getElementById("urlbar").inputField.focus(); ?

Comment 12

[Robert Kaiser]

Attachment: v 1.3: focus input field right away

yes, .inputField.focus() works fine, thanks!

Comment 13

[Robert Kaiser]

Pushed as http://hg.mozilla.org/comm-central/rev/671042296bda