Closed Bug 597190 Opened 14 years ago Closed 14 years ago

#map stopped working in HTML signature ("usemap" attribute is actively deleted from it)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 597784

People

(Reporter: fesq, Unassigned)

References

Details

(Keywords: regression)

Attachments

(4 files)

GIF file being referenced in the HTML signature file
7.76 KB, image/gif
Details
HTML signature file
751 bytes, text/html
Details
Test e-mail sent with v3.1.2 that shows the "map" working just fine
13.51 KB, application/octet-stream
Details
Test e-mail with v3.1.4 with the usemap attribute stripped off
13.63 KB, application/octet-stream
Details 
User-Agent:       Opera/9.80 (Windows NT 5.1; U; en) Presto/2.6.30 Version/10.62
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

I use an HTML signature file which references a GIF file defining a map ("ismap") over it, specifying the "usemap" to give the map's name to the "img src" tag.

This worked just fine in versions up to 3.1.2; from 3.1.3 and now 3.1.4 every time the mail is sent, Thunderbird strips the 'usemap' attribute from the 'img src' tag and then the links from the image don't work.

Reproducible: Always

Steps to Reproduce:
1. Use the attached HTML and GIF files as a signature for an account
2. Send a test e-mail
3. Check the source of the received mail: You won't see the 'usemap' attribute in the 'img src' tag, so the links the map defines won't work.
Actual Results:  
The links defined by the map inside the GIF don't work.

Expected Results:  
Clickable links inside the GIF file (3 of them) used to work just fine up until version 3.1.2

This is the HTML signature file. Note the 'usemap' attribute in the 'img src' tag referencing "#theMap": It gets stripped off when the mail is finally sent...

<map name=theMap>
  <area href="mailto:Fabio.Esquivel@TecniCard.com" alt="Personal e-mail" coords="45,4,223,22">
  <area href="mailto:SoportePE@TecniCard.com" alt="Support e-mail" coords="130,22,224,35">
  <area href="http://www.sistemasgalileo.net" alt="Website" coords="63,37,234,64">
</map>
<table frame="void" border=0>
  <tr>
    <td align="center">
      <img src="file://localhost/F:/Thunderbird/tecnicard-sig.gif" ismap="ismap" usemap="#theMap" border=0 width=240 height=110></a>
  <tr>
    <td align="right">
      <small>
        <i>We don't make mistakes here.<br>
        We just learn great lessons.</i><br>
        -- Steve McGarret&nbsp;&nbsp;<br>(Hawaii Five-O)&nbsp;&nbsp;
      </small>
    </td>
  </tr>
</table>
Attached file HTML signature file — 

    
  
Version: unspecified → 3.1

    
  
Summary: #map stopped working in HTML signatures ("usemap" is actively deleted from it) → #map stopped working in HTML signature ("usemap" attribute is actively deleted from it)
Blocks: CVE-2010-2769
blocking-thunderbird3.1: --- → ?
Component: Message Compose Window → Composition
Keywords: regression
Product: Thunderbird → MailNews Core
QA Contact: message-compose → composition
Version: 3.1 → unspecified

    
    

    
  
Ludovic, what do you mean by "reproduce"? Do you want me to transcribe all I said in that URL too?

    
  
Version: unspecified → 1.9.2 Branch

    
    

    
  
Ok, I copy/pasted the HTML signature in "View HTML Source" mode; then switched back and forth the view by clicking on that option.

The "usemap=" attribute does not get stripped off in that box and the links are visible and active every time.

So the bug does not happen in there, but it still happens in Thunderbird v3.1.4 (since v3.1.3 as far as I can tell).

    
    

    
  
(In reply to comment #5)
> Ok, I copy/pasted the HTML signature in "View HTML Source" mode; then switched
> back and forth the view by clicking on that option.
Thanks

    
    

    
  
Hmm, so what's happening here is that the <area> elements are not injected at all.  I set a breakpoint on nsHTMLParanoidFragmentSink::OpenContainer and nsHTMLParanoidFragmentSink::AddLeaf, and they're never called for the <area> elements.  Henri, does the HTML parser handle these elements in a special way?

    
    

    
  
Well, I don't know about the parser, but the <area> elements ARE present in the final e-mail being sent... This is the source of the received mail:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-8859-1">
  </head>
  <body bgcolor=3D"#ffffff" text=3D"#000000">
    <div class=3D"moz-signature">-- <br>
      <map name=3D"theMap">
        <area href=3D"mailto:Fabio.Esquivel@TecniCard.com" alt=3D"Personal e-mail" coords=3D"45,4,223,22">
        <area href=3D"mailto:SoportePE@TecniCard.com" alt=3D"Support e-mail" coords=3D"130,22,224,35">
        <area href=3D"http://www.sistemasgalileo.net" alt=3D"Website" coords=3D"63,37,234,64">
      </map>
      <table border=3D"0" frame=3D"void">
        <tbody>
          <tr>
            <td align=3D"center"> <img src=3D"cid:part1.06090606.06020506@tecnicard.com"
                ismap=3D"ismap" border=3D"0" height=3D"110" width=3D"240"> </td>
          </tr>
          <tr>
            <td align=3D"right"> <small> <i>We don't make mistakes here.<br>
                  We just learn great lessons.</i><br>
                -- Steve McGarret&nbsp;&nbsp;<br>
                (Hawaii Five-O)&nbsp;&nbsp; </small> </td>
          </tr>
        </tbody>
      </table>
    </div>
  </body>
</html>

Notice the absence of the "useMap" attribute for the <img src> element (it's present in the source HTML file I attached): Should it be there, the links in the image would work just fine, just like they used to work in Thunderbird versions prior to 3.1.2.

    
    

    
  
(In reply to comment #7)
> Hmm, so what's happening here is that the <area> elements are not injected at
> all.  I set a breakpoint on nsHTMLParanoidFragmentSink::OpenContainer and
> nsHTMLParanoidFragmentSink::AddLeaf, and they're never called for the <area>
> elements.  Henri, does the HTML parser handle these elements in a special way?

The paranoid sink is still using the old parser. <area> was special in the old parser: it was ignored outside <map>. Other than that, I don't know what the old parser does.

    
    

    
  
(In reply to comment #9)
> (In reply to comment #7)
> > Hmm, so what's happening here is that the <area> elements are not injected at
> > all.  I set a breakpoint on nsHTMLParanoidFragmentSink::OpenContainer and
> > nsHTMLParanoidFragmentSink::AddLeaf, and they're never called for the <area>
> > elements.  Henri, does the HTML parser handle these elements in a special way?
> 
> The paranoid sink is still using the old parser. <area> was special in the old
> parser: it was ignored outside <map>. Other than that, I don't know what the
> old parser does.

Hmm, but in this test case <area> elements _are_ inside the <map>...

Is there a bug on file to move the paranoid sink to the new parser?  Or is there someone else who I can ask about this?

Thanks!

    
    

    
  
(In reply to comment #10)
> Is there a bug on file to move the paranoid sink to the new parser?  

Bug 482909.

> Or is
> there someone else who I can ask about this?

mrbkap, I suppose.

    
    

    
  
mrbkap, can you please see comment 7 and let me know if you have any ideas?  Thanks!
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Does mrbkap ever show to work? :-)

    
    

    
  
I'm not going to have time to look into this at all for a little while... I do know that if there's an open map, then we'll call AddLeaf on the sink; but beyond that I don't know why this wouldn't work.

    
    

    
  
I just downloaded the official v3.1.2 release (the one I'm sure the map worked just fine in the signature): Installed it, ran it, verified the release () and the usemap="#theMap" attribute for the 'img src' tag is there.

That attribute gets stripped off since v3.1.3. I'm attaching a test e-mail I sent to myself to show how map is used and kept just fine in this release.

    
    

    
  
... sorry, forgot to paste the ID: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

    
    

    
  
Now I reinstalled v3.1.4 and resend myself another test e-mail (Test #2, attached) so you can see the usemap attribute is not there anymore.

ID: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

    
    

    
  


  
This stripping off of the usemap attribute happens since v3.1.3.

    
    

    
  
Fabio can you try to use the nigthlies found at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/ s we can find two versions with one or two days appart ?

    
    

    
  
I'm sorry, guys, but I'm lost here... What nightlies exactly do you want me to test out?

The bug I'm reporting happens since v3.1.3: Under http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.1.3-candidates/build1/win32/en-US/ there's just one build to download and test, no "nightlies".

Focusing on the revision numbers, rv:1.9.2.8 worked just fine but rv: 1.9.2.9 presents the bug. Can you tell me which of the nightlies in http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/ should I download and test?

Besides, I already gave you the GIF, the HTML signature that references it via a map attribute in the 'img src' tag, working examples (in .eml format) of the signature working fine (v3.1.2) and then not working too... Can you just try to reproduce the error and see where Thunderbird "lost it"?

I'm new at this (reporting bugs) but I think I had done things right (explain in detail the bug, give out the involved files and examples, tried to reproduce the behaviour in different versions, reported back to you, etc.), but you still seem to depend on my own diagnosis...

You have all the elements to reproduce the bug, the time (I hope) and the access to the nightlies as well, why don't you just take the time to debug with the code at hand?

    
    

    
  
Can a mailnews developer please bisect a large regression range to determine the exact culprit changeset?

    
    

    
  
(In reply to comment #23)
> Can a mailnews developer please bisect a large regression range to determine
> the exact culprit changeset?

Joe ?

    
    

    
  
Fixed on current tinderbox builds.
.5 will contain the fix.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
blocking-thunderbird3.1: ? → ---

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: